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 220.127.116.11 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:email@example.com]
>>Sent: Friday, June 17, 2005 10:54 AM
>>Subject: Re: Unclear: CVS and Subversion repository difference.
>>On Jun 17, 2005, at 10:29 AM, firstname.lastname@example.org 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
>>That's why svn, for example, has branches and tags named
>>'1.1.x' and '1.1.4'. *Those* are the only labels that matter.
>Hmmm. Revision numbers are reported under the "Known Bugs" section on
>the subversion download site. So there is an interpretation used by the
>subversion team that indicates maturity (assuming fixed bugs indicates
>more mature). It also seems to be common to treat the revision number as
>a build number again making it something more than just background
>It seems to me the revision number absolutly does indicate a version of
>a project at a given point in time.
>To unsubscribe, e-mail: email@example.com
>For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jun 17 19:26:41 2005