Re: Creating something like increasing revision numbers

From: alexandrul <alexandrul.ct@gmail.com>
Date: Oct 18, 2009, 16:35 UTC
Message-ID: <4ADB43EA.5060901@gmail.com>
In-Reply-To: <9b18b3110910180916s2a2ac751i7520e64294037817@mail.gmail.com>

demerphq wrote:

Show 14 quoted lines

> Consider you have A-B-C-D-E in your master repo. So presumably numbered 1..5.
> 
> If i then make a trivial comment fix to A and then merge and push we
> end up with:
> 
> A-B-C-D-E-G
>  \        /
>   F------+
> 
> If i understand you right you will set F to 6 and G to 7. Thus youll
> end up with the problem that F is a descendent of A yet has a higher
> "version number" than E. You can repeat this process for ever.
> 
> If this suits your needs then great.

Just like subversion :D

It helps by ordering commits by time, not by parents, and I don't need repo access to figure it out that F is the latest bug/feature/fix.

Think about 2 sql servers, each has different versions of the same stored procedure. Which one is newer, given that you don't have the git repository on the production servers? I can't make any decision on SHA1 only, and if they belong to the same branch ("prod") I'm so out of luck. At the moment I'm saving SHA1, refs, author date, comitter date and last subject. But it's easier for me to compare revision numbers than dates. And don't forget that updating decisions may be taken by people that have nothing to do with development.

Have a nice day,
  A.