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 commits. 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 ordering. 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 does. >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 operations. 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 with. -- Boyd Stephen Smith Jr. ,= ,-_-. =. email@example.com ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Description: This is a digitally signed message part.