You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Servico Tpd Rodrigo Alfonso Menezes Madera <tp...@telefonica.com.br> on 2005/06/16 23:46:09 UTC
Unclear: CVS and Subversion repository difference.
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
Re: Unclear: CVS and Subversion repository difference.
Posted by Michael W Thelen <mi...@pietdepsi.com>.
Servico Tpd Rodrigo Alfonso Menezes Madera wrote:
> 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 see chapter 2 of the book, specifically the section on Revisions:
http://svnbook.red-bean.com/en/1.1/ch02s03.html#svn-ch-2-sect-3.2
You may also find the "Subversion for CVS Users" appendix to be useful:
http://svnbook.red-bean.com/en/1.1/apa.html
--
Michael W Thelen
It is a mistake to think you can solve any major problems just with
potatoes. -- Douglas Adams
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unclear: CVS and Subversion repository difference.
Posted by Frank Gruman <fg...@verizon.net>.
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
Re: Unclear: CVS and Subversion repository difference.
Posted by Marc Haisenko <ha...@webport.de>.
On Friday 17 June 2005 09:57, Marc Haisenko wrote:
> Some else edits and commit /foo/abc, which is now at r2. But in your
> directory it's still at r1. You then edit /foo/bar and commit, and it will
> be at r3, while your /foo/abc is still at r1. This is to reduce network
> traffic, AFAIK, and to avoid surprises: imagine you commat /foo/bar and
> suddenly
> your /foo/abc is different !
s/some else/someone else/
s/commat/commit/
I think I really should get my coffee before posting...
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unclear: CVS and Subversion repository difference.
Posted by Marc Haisenko <ha...@webport.de>.
On Friday 17 June 2005 01:46, Servico Tpd Rodrigo Alfonso Menezes Madera
wrote:
> 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.
Just do "svn up" in both directories and all files will be at r5.
When you commit, a directory can then contain mixed revisions. Imagine the
following layout:
/foo/abc (r1)
/foo/bar (r1)
Some else edits and commit /foo/abc, which is now at r2. But in your directory
it's still at r1. You then edit /foo/bar and commit, and it will be at r3,
while your /foo/abc is still at r1. This is to reduce network traffic, AFAIK,
and to avoid surprises: imagine you commat /foo/bar and suddenly
your /foo/abc is different !
A simple "svn up" will fix this mixed revision issue.
> Please show me up some light. I´m scared...
Don't be scared, you will soon see the light and never look back at CVS
again ;-)
> Thanks for your patience,
> Rodrigo
C'ya,
Marc
--
Marc Haisenko
Systemspezialist
Webport IT-Services GmbH
mailto: haisenko@webport.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unclear: CVS and Subversion repository difference.
Posted by John Waycott <ja...@cox.net>.
Ben Collins-Sussman wrote:
>
> On Jun 16, 2005, at 8:56 PM, Ron Gilbert wrote:
>
>>
>> True, but then you have the version number issue. I don't want all
>> my projects jumping up a version number when they are 100% unrelated.
>
>
> This isn't a problem; you just imagine to be. Lots of subversion
> newbies think that it matters, and it just doesn't. Here's a FAQ
> about it:
>
> http://subversion.tigris.org/faq.html#globalrev
>
> Seriously, just try it out. When the global revision increases, it's
> a meaningless thing.
>
Yes, even the CVS gurus say you should not really pay much attention to
file revisions. You are supposed to use tags.
I've had problems explaining this concept to our developers (PVCS and
CVS users). The one explanation they seem to understand is to think of a
repository revision as a tag; Once they understand this, they really
like it because they realize that the policy we had of tagging CVS every
time you branch or merge isn't necessary anymore. The /tags directory
can then be used for those tags that are truly important to the project.
John Waycott
Hypercom Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unclear: CVS and Subversion repository difference.
Posted by Ron Gilbert <li...@rzweb.com>.
> This isn't a problem; you just imagine to be. Lots of subversion
> newbies think that it matters, and it just doesn't. Here's a FAQ
> about it:
Well, it does matter to me. Sorry we'll just have to respectably disagree. And don't get me wrong, I like the global version number for the project much better than a per-file version number.
Anyway, non-issue because you can simply create multiple repositories, and I find that a better solution anyway, as the thread originator might as well.
Maybe my situation is different from yours, but I am dealing with several projects with many offsite contract programmers and artists and they can not always have read access to all the projects.
> If you're using svn://, then you can control per-directory write-
> access via a pre-commit hook script.
But read access is exactly what I need to control, hence the multiple repositories.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unclear: CVS and Subversion repository difference.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 16, 2005, at 8:56 PM, Ron Gilbert wrote:
>
> True, but then you have the version number issue. I don't want all
> my projects jumping up a version number when they are 100% unrelated.
This isn't a problem; you just imagine to be. Lots of subversion
newbies think that it matters, and it just doesn't. Here's a FAQ
about it:
http://subversion.tigris.org/faq.html#globalrev
Seriously, just try it out. When the global revision increases, it's
a meaningless thing.
>
> And, how would you control the access rights if they were in the
> same repository (I am using svn://)? Am I missing something obvious?
>
If you're using svn://, then you can control per-directory write-
access via a pre-commit hook script. There's no way to control per-
directory read-access. If you're using http://, then mod_authz_svn
can control both read and write access.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unclear: CVS and Subversion repository difference.
Posted by Ron Gilbert <li...@rzweb.com>.
> ?? People put multiple projects into a single subversion repository
> all the time. Look at the ASF's or KDE's repository, for example.
> And you can definitely still control access rights per-directory.
True, but then you have the version number issue. I don't want all my projects jumping up a version number when they are 100% unrelated.
And, how would you control the access rights if they were in the same repository (I am using svn://)? Am I missing something obvious?
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unclear: CVS and Subversion repository difference.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 16, 2005, at 8:25 PM, Ron Gilbert wrote:
> I had this same conceptual problem when I convert to Subversion,
> and what finally dawned on me was just create a new repository for
> the different projects. In CVS (and other systems), you dump
> everything into one repository, but with Subversion, just make
> different ones. Doing this also allows you to have different
> access rights for different users.
>
?? People put multiple projects into a single subversion repository
all the time. Look at the ASF's or KDE's repository, for example.
And you can definitely still control access rights per-directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unclear: CVS and Subversion repository difference.
Posted by Ron Gilbert <li...@rzweb.com>.
I had this same conceptual problem when I convert to Subversion, and what finally dawned on me was just create a new repository for the different projects. In CVS (and other systems), you dump everything into one repository, but with Subversion, just make different ones. Doing this also allows you to have different access rights for different users.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unclear: CVS and Subversion repository difference.
Posted by "Matthew S. Moore" <mm...@asf.alaska.edu>.
Servico Tpd Rodrigo Alfonso Menezes Madera wrote:
> 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??
In a sense, yes, but only because the revision level of the whole repository is
incremented.
> 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.
The reason you are seeing mixed revisions is because the svn is reporting the
last revision that was changed.
To better explain this:
$ svnadmin create /svn/repos
$ svn checkout file:///svn/repos ~/wc
Checked out revision 0.
-- make a default directory tree for two projects and commit:
$ svn commit -m "default tree"
Adding proj1
Adding proj1/branches
Adding proj1/tags
Adding proj1/trunk
Adding proj1/trunk/bin
Adding proj1/trunk/doc
Adding proj1/trunk/src
Adding proj2
Adding proj2/branches
Adding proj2/tags
Adding proj2/trunk
Adding proj2/trunk/bin
Adding proj2/trunk/doc
Adding proj2/trunk/src
Committed revision 1.
$ cd proj1/trunk/src
$ echo line1 > file1.c
$ svn add file1.c
A file1.c
$ svn commit -m "adding first file for proj1"
Adding src/file1.c
Transmitting file data .
Committed revision 2.
$ cd ../doc
$ echo line1 > file1.txt
$ svn add file1.txt
A file1.txt
$ svn commit -m "adding second file for proj1"
Adding doc/file1.txt
Transmitting file data .
Committed revision 3.
$ cd ~/wc/proj2/trunk/src
$ echo line1 > file1.pl
$ svn add file1.pl
A file1.pl
$ svn commit -m "adding first file for proj2"
Adding src/file1.pl
Transmitting file data .
Committed revision 4.
-- Now we can see how the revisions actually look:
$ svn info ~/wc/proj1/trunk/src/file1.c | grep Rev
Revision: 2
Last Changed Rev: 2
$ svn info ~/wc/proj1/trunk/doc/file1.txt | grep Rev
Revision: 3
Last Changed Rev: 3
$ svn info ~/wc/proj2/trunk/src/file1.pl | grep Rev
Revision: 4
Last Changed Rev: 4
-- The reason the revisions are all different is because we made all of our
commits to a single file and did not update the whole working copy:
$ cd ~/wc
$ svn update
At revision 4.
$ svn info ~/wc/proj1/trunk/src/file1.c | grep Rev
Revision: 4
Last Changed Rev: 2
$ svn info ~/wc/proj1/trunk/doc/file1.txt | grep Rev
Revision: 4
Last Changed Rev: 3
$ svn info ~/wc/proj2/trunk/src/file1.pl | grep Rev
Revision: 4
Last Changed Rev: 4
-- Furthermore, let's baseline proj1 and call it Release 1:
$ svn copy -m "Release 1" file:///svn/repos/proj1/trunk \
file:///svn/repos/proj1/tags/proj1_Release_1
Committed revision 5.
$ svn update
A proj1/tags/proj1_Release_1
A proj1/tags/proj1_Release_1/doc
A proj1/tags/proj1_Release_1/doc/file1.txt
A proj1/tags/proj1_Release_1/src
A proj1/tags/proj1_Release_1/src/file1.c
A proj1/tags/proj1_Release_1/bin
Updated to revision 5.
$ tree proj1
proj1
|-- branches
|-- tags
| `-- proj1_Release_1
| |-- bin
| |-- doc
| | `-- file1.txt
| `-- src
| `-- file1.c
`-- trunk
|-- bin
|-- doc
| `-- file1.txt
`-- src
`-- file1.c
10 directories, 4 files
$ svn log -v -r 5
------------------------------------------------------------------------
r5 | mmoore | 2005-06-16 18:17:58 -0800 (Thu, 16 Jun 2005) | 1 line
Changed paths:
A /proj1/tags/proj1_Release_1 (from /proj1/trunk:4)
Release 1
------------------------------------------------------------------------
So, proj1_Release_1 revision 5 is just a copy of proj1/trunk at revision 4.
In other words you define the releases however you want, but the revisions keep
incrementing for the whole repository with every commit. I hope this helps!
Matthew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org