I don't actually *use* Subversion yet, but I'm thinking about it (moving CVS to Subversion.) I read the PDF version of The Book (http://svnbook.red-bean.com/en/1.1/svn-book.pdf) and the description and picture (figure 2.7) starting on page 16 really helped me.
Revisions in CVS are arbitrary and have no meaning other than the sequence of a particular archive. In other words, revision 1.4 of a file has nothing to do with revision 1.4 of any other file, necessarily.
With subversion, the whole tree gets the revision number, so revision 6 of a file is forever related to revision 6 of any other file in the repo, a snapshot in time. This made a lot of sense to me once I wrapped my head around it. Revision 2 through 6 of a file (most files, probably) may be identical, but the rub is that they are referenceable in a meaningful way (as they relate to the whole tree.)
To extend a little further, the lack of true tags/labels in Subversion at first threw me off, but it made sense that it was redundant once I learned about the way the system works. If you really need to, you can literally refer to a code base as 'version 108' as a whole and it will mean the same thing to every file in the tree. (Although branching into the labels/tags directory makes things prettier and easier to find.)
Two cents from a guy that doesn't even use Subversion. Ha!
-Matt
-----Original Message-----
From: Frank Gruman [mailto:fgatwork@verizon.net]
Sent: Thursday, June 16, 2005 5:15 PM
To: Servico Tpd Rodrigo Alfonso Menezes Madera
Cc: users@subversion.tigris.org
Subject: Re: Unclear: CVS and Subversion repository difference.
Rodrigo,
I've never used CVS, so am not clear how it does things, but I have come
to very much like the way Subversion does things.
There are other here who could give you the technical 'this is the way
the developers wrote it' description and point you back to the book, but
here is my take:
A revision is just another way of looking at the code at a specific
point in time. As it does say in the book
(http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-3-sect-3.3 and
yes, I just did the pointer thing), you can also do any search by date
rather than a revision number. The concept of using the revision number
as a 'version' number is something that seems to be tough to get over.
I am fighting that battle with one of my developers right now. It
really isn't a true 'version'. It is only saying that at this point in
time, all of the code in this repository looked this way.
In your scenario, there are multiple 'projects' that have nothing to do
with each other, and it worries you that some number is being assigned
to the repository as a whole when it was really only one 2 kB file at
the back end of one project. And what's more, folders and files all
show different revisions. Well - fear not, my friend.
Synopsis of revisioning :
/trunk = Repository Top Level = the latest change made to _ANY_ file in the repository (regardless of where, when, or who) = 'HEAD' revision in the repository.
/trunk/project1 = as a project directory within the repository, when you look at it, it will report back the latest change made to _ANY_ file
within that particular folder and all subfolders.
/trunk/project1/directory1/file1234.56 = any file in the repository will hold a revision number equal to the last change made to that particular
file.
As I said earlier, I look at a revision as not much more than a simple
time stamp. It is incremental to make it easier to find some things
(give me all code at revision 123 because some goof ball checked in
broken code at 124). This way, I don't care about the time stamp.
On one of my projects, the developers don't pay much attention to the
revision numbers since we can use specific dates. They built a build
tool that pulls the code from the repository as of a specified date/time
and does an application build. This way, the developers never have to
stop coding/checking things in, and the build team can sit down on a
Thursday and say that the code as of Tuesday at 1900 contained the
fixes/enhancements to our product. So far, we haven't run into _ANY_
problems. I love Subversion.
OH - btw - we have one repository that contains 7 disparate projects.
Nothing common between them.
I hope that helps. Also - I just noticed while typing up this little
book that someone already pointed you to other parts of 'The Book'. :-)
Regards - I'm going to go have another glass of wine.
Frank
Servico Tpd Rodrigo Alfonso Menezes Madera wrote:
>
>
>Hello to all,
>
>The whole idea of Subversion over CVS looks good but requires some time to
>master
>the fine details it has. And itīs in this respect that the wise Mr. Google
>couldnīt answer me
>even after insisting for hours and having made some research on a detail
>that means so
>much to our teamwork. Iīve read the Subversion manual 1.0 and 1.1. Twice
>each... I Canīt
>seem to clear this up.
>
>Itīs all bound to one simple mighty question...
>
>Imagine you have a repository in "/home/subversion" and you add two
>projects that have
>nothing to do with each other whatsoever. Say ChessGame and Spreadsheet are
>both
>imported to the repository. They are from different teams. "Nada" in
>common.
>
>So, what every text that Iīve interpreted says (but makes no sense to me)
>is that whenever
>I make changes to ChessGame, the release is incremented for both projects
>because the
>release number is only altered on the repository. Thus if I add a file
>called "HowToPlay" to
>the ChessGame project, the Spreadheet aplication has itīs release
>incremented. Is this
>what actually happens??
>
>Well, since I am a programmer, I did what programmers do in such a case...
>I researched
>(after Google said he wouldnīt comment on the subject) and made a handful
>of tests. The
>result only made my mind almost blow. I ran TortoiseSVN (I know, I know,
>Iīm only mentioning
>it on this list, not a problem in it whatsoever) and became even more
>confused: even though
>my ChessGame directory had release 5, the file DrawChessBoard.c++ had a
>release of 1, the
>"src" directory had a release 3, and you can imagine all this confusion
>that a goodīol CVS
>user has to understand.
>
>Please show me up some light. Iīm scared...
>
>Thanks for your patience,
>Rodrigo
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
**********************************************************************
E-mail sent through the Internet is not secure. Western Asset therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Western Asset therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail.
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 17 02:36:10 2005