Re: Creating something like increasing revision numbers

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 18, 2009, 21:43 UTC
Message-ID: <alpine.LNX.2.00.0910181727130.32515@iabervon.org>
In-Reply-To: <20091018144158.GA9789@gandalf.dynalias.org>

On Sun, 18 Oct 2009, Norbert Preining wrote:

Show 28 quoted lines

> Dear all,
> 
> (please Cc)
> 
> I am managing some of my projects with git and I am quite happy about it.
> 
> There is another project I am working that is quite big, the subversion
> checkout is about 14Gb. Doing svn up is a pain, it has to open tens of
> thousands of files and directories traversing the whole tree, trashing
> the fs cache and taking ages.
> 
> My idea was to move to git, from what I read it should be more capable
> in handling these type of projects.
> 
> Now, there is one show-stopper I see. From our repository we create a
> set of "packages", and the maximum of the "last-changed" revisions of
> the contained files determine the "version" of the package. This 
> guarantees that any change in a file will increase the revision number
> of the package (some tricks for removals have to be done). This is necessary
> since we are distributing the packages from servers and the version number
> pf a package determines whether it should be upgraded (well known concept).
> 
> Now my question, is there any way to set up something similar with git?
> 
> My idea is that git - like subversion - could (if asked to) count each
> commit (global to the repository, irrelevant of the branch) and give it
> a version number. Since we all will use a bare repository on a server
> and pull/push from/to there, I think that something similar could be possible.

It's possible as long as you don't think of the "version number" as a property of the commit, but rather a property that some commits get by virtue of having been at some time the commit that's what would be found on that particular server at that particular time. Even though the history of the *content* is non-linear, the sequence of values stored in refs/heads/master on your central server is linear, local, and easy to enumerate.

Of course, when someone does a bunch of development in parallel with other people, does a final merge, and pushes it back to the server, this only increases the version by one, and only the final merge actually has a version number at all. For your application, this shouldn't be a problem, because the intermediate commits don't ever get packages created of them to need to be compared to other packages.

	-Daniel
*This .sig left intentionally blank*