[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Unclear: CVS and Subversion repository difference.

From: Frank Gruman <fgatwork_at_verizon.net>
Date: 2005-06-17 19:24:07 CEST

All,

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
/trunk/project2/foo.d)

Version - a compilation/label of the code in the repository at a
specific point in time. (e.g. Version 1.0.0.86 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. :-)

Regards,
Frank

I have sear
Rule, Chris wrote:

>>-----Original Message-----
>>From: Ben Collins-Sussman [mailto:sussman@collab.net]
>>Sent: Friday, June 17, 2005 10:54 AM
>>To: ed.wittmann@fiserv.com
>>Cc: users@subversion.tigris.org
>>Subject: Re: Unclear: CVS and Subversion repository difference.
>>
>>On Jun 17, 2005, at 10:29 AM, ed.wittmann@fiserv.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
>>software's maturity.
>>
>>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
>noise.
>
>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: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
Received on Fri Jun 17 19:26:41 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.