[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Your favorite version control software

On 2011-03-25 14:00:26 Gregory Seidman wrote:
>Either I don't get it or I won't drink the Kool-Aid. It's hard to say
>which. I understand the value of the decentralized approach for a
>decentralized project. That includes many open source projects. I believe
>that git is absolutely the best choice for the Linux kernel, for example.
>On the other hand, I *really* value a repository-wide, monotonically
>increasing version number. When I'm setting up source control for a
>project, I'll always go with subversion. Even if everyone working on the
>project uses git through git-svn and pulls changesets from one another, I
>want the central repository to have sequential revision numbers for
>commits. I want to be able to identify a revision number in a release that
>indicates all of the commits of which it is composed (i.e. any number less
>than that revision number). The whole GUID thing is fine for passing
>changes around, but it's meaningless for a release.

git-describe provides friendlier descriptions of many trees.  If you tag 
names sort well, then the output of git-describe sorts well for the 
majority of commits.

Given a SHA and the repository, it is trivial to list all the commits that 
are ancestors of it.  The output of git-describe provides enough context to 
usually get the whole SHA.

Finally, if you just gotta have monotonically increasing numbers, it's 
relatively easy to trivial to have a hook on the central repository that 
generates tags automatically that use monotonically increasing numbers.

The problem with monotonically increasing numbers is that they don't make 
sense for every commit in a non-linear history, because while there is a 
partial ordering of such commits, there is not a total ordering on such 

The "trick" with the tags generated by a hook like I suggested is that it 
doesn't attempt to assign a number of *every* commit.  Instead, it only 
assigns numbers to the synchronization points.  Assuming the central 
repository is updated in a fast-forward manner (generally a good idea, and 
the default unless someone uses --force), then these synchronization points 
are a subset of commits in the non-linear history that DO have a total 

Bzr uses hashes/ids "behind the scenes" but generally recommends using 
something very close to numbers.  Given a repository, each "synchronization 
point" is assigned a monotonically increasing number.  Commits that aren't 
synchronization points, use a multiply-dotted syntax after the number that 
identifies the most recent "synchronization point".  It gives a very SVN 
like feel; the HEAD/trunk/master branch in the central repository is always 
at something that can be called "revision N" where n is a natural number.  
It's not entirely the same though, a local commit might be called "304" 
until you synchronize with someone else (like the central repository) and 
it starts being called "300.1.4".  That only (I think) happens to private 
commits though; there's some guarantee that when you and someone else share 
a commit, it will have the same name for both of you.

Hg and Mtn might also have solutions in this area.  I tend to doubt Darcs 

>So, yeah, git is great on the client side, but I want a central repository
>that is more oriented toward points in time than changesets. I can have
>both with git-svn.

Git, Hg, and Mtn are not changeset oriented at all.  Any diffs they present 
as part of a log are synthesized at that time.  They (efficiently) store 
"snapshots" of the repository, and are not much concerned with how the 
repository got there.  Darcs is very changeset oriented, it juggles patches 
not snapshots.  It synthesizes the work tree as necessary, and understands 
patch dependencies enough to make that work tree deterministic.  However, 
it doesn't fundamentally store states, be rather transitions between 
states.  I think Bzr is similar to Git/Hg/Mtn, but I know it has some 
relationship with Arch so (like Arch) it might use changesets for some 

So, with Git/Hg/Mtn a commit's hash/id *is* a unique identifier of a point 
in time, which is what you claim you are after.

I tend to think that monotonically increasing natural numbers are a bit 
over-rated.  However, if you want them you can get them without completely 
abandoning a non-linear history and some of the DVCS advantages that comes 
Boyd Stephen Smith Jr.           	 ,= ,-_-. =.
bss@iguanasuicide.net            	((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy 	 `-'(. .)`-'
http://iguanasuicide.net/        	     \_/

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: