Ben,
> If you guys don't read the docs and don't understand the
> basic concepts of SVN, I can't help you.
We had previously RTFM, the whole 278 pages of it, plus the 87 pages
from the TortoiseSVN manual, plus the 24 pages of the FAQ. I'm not
claiming that we know it by heart nor that we fully understood
everything and the implications, though. Preliminary RTFM is a necessary
condition to understanding, but it's not a sufficient condition - thus
my presence on this list.
As I said before, my current understanding of what happened to us on our
first use is that we checked out the whole repository from the root,
while we only intented to checkout the head of the project.
What I have been trying to explain is that something like this simply
couldn't happen with CVS using the similar TortoiseCVS interface, just
because the only thing TortoiseCVS allows us to checkout with that setup
is a single project - not a whole repository.
Still using TortoiseCVS, I can also create subdirs, stuff a subproject
into each subdir, and work at the subproject (subdir) level if I want
it. And then, it's up to me to manage my directory tree, because if I
damage my tree, CVS will record the damage and I'll have to get back
somehow.
So in this strict respect, the CVS "Project" (or "Module" as Tortoise
calls it) appears to me as more or less the functional equivalent of the
svn "Repository".
IOW I don't really care whether our CVS keeps everything physically in a
big repository, as long as *using the client interface*, I have the
ability to use this project-by-project logical protection - or to not
use it. This allows us to organise our projects the way we want it, and
protect us from ourselves when we want it (by creating a separate
project), so they live in different directory trees.
To get a similar fonctionnal level of protection with svn, I have to
create a separate repository.
Which requires that I login to the Linux machine, because svn doesn't
allow me to do it using the client tools.
Which also requires that I remember about setting FSFS and fix the
svnserve.conf file, or that I create specific scripts and that everyone
remembers to use them for repository creation.
Or which requires that one of us becomes "administrator" and takes
responsability for that delicate stuff.
So in our context and in that strict respect, svn looks a bit less
convenient to us than what we are used to.
This doesn't mean we do not appreciate the numerous things that svn does
and that CVS doesn't even come near. Simply, the organisation of the
team and team work is an important factor, and I needed to make real
sure I wasn't missing something, like a workaround for that problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 18 18:06:27 2005