Re: Creating something like increasing revision numbers

On Sun, 18 Oct 2009, Norbert Preining wrote:

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*