One of our developers decided to time stamp entries in a log using the system
time (i.e. seconds since 1970):
% perl -e 'print time()."\n";'
To most people (including myself) I found reading these log files difficult
because this number is meaningless until I translated it to something useful:
% perl -e 'print localtime(1119030451)."\n";'
Fri Jun 17 17:47:31 2005
My point is to think of the repository revision as some large number that
constantly increases over time. Sure you can use this number meaningfully, but
it helps to translate important repository revisions to a version/release number
that can be understood by anyone.
Frank Gruman wrote:
> Maybe it's just me, but there seems to be a lot of interchange between
> the use of the word 'revision' and the use of the word 'version'. I
> think some people are getting hung up on this, but (at least for me)
> they are two relatively separate entities.
> Here are my definitions for these two words:
> Revision - a change to any piece of code in the repository. (e.g.
> Revision 1234 might contain a change to file /trunk/project1/foo.c and
> Version - a compilation/label of the code in the repository at a
> specific point in time. (e.g. Version 18.104.22.168 might contain the code
> that was affected by revision 1233, 1234, etc)
> A revision is one of a thousand different mutations to source code that
> culminates in a compiled/released version. Revision = small piece of
> picture. Version = big picture.
> And back to the original post - create two separate repositories. It
> will save on trying to discuss revisions / version with your people. :-)
> I have sear
> Rule, Chris wrote:
>>>From: Ben Collins-Sussman [mailto:firstname.lastname@example.org]
>>>On Jun 17, 2005, at 10:29 AM, email@example.com wrote:
>>>>So I got them to talk about Release numbers in terms of phase and
>>>>number (2.17, phase 2, release 17) and to let me worry about the
>>>>revision numbers, and now everyone's happy. All I use the revision
>>>>numbers for now is to determine what diffs to merge into my release
>>>>candidate branches, and I gather those based on our issue tracking
>>>>tool. When I'm done gathering those diffs into my release candidate
>>>>branch, I tag and move on.
>>>This is the key concept. A global repository revision has
>>>absolutely nothing to do with the "version" of any project
>>>within the repository. A project needs to invent its own
>>>release numbering system and stick to it. A changing global
>>>repository revision is just background noise, handles you can
>>>use to move around in time, but totally unrelated to the
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Jun 17 20:01:16 2005