On Wed, 2004-02-18 at 17:39, Marcin Kasperski wrote:
> When I got to the
> section about 'svn switch' it was 'eureka, I need not!' but this section
> is far away from the discussions about repo dirs structure where those
> thoughts come to mind.
Ah, point taken. I'll at least make a one sentence cross-ref link to
the 'switch' section. Thanks.
> By the way: does subversion allow me to do something similar to
> cvs log -r oldtag -r newtag
You're stuck in cvs-mode. Tags are not labels across the 'default
branch', but rather are entire tree copies. You're asking the question
in a cvs way.
In subversion, you have directories A and B, and both are tags of
trunk. You run 'svn log' on the two directories to see exactly where
they were copied from. You learn than A is a copy of revision X of
trunk, and B is a copy of revision Y of trunk. So you then run "svn log
-rX:Y trunkURL" to see all changes that happened on the trunk between
the tagging events.
> really be worth mentioning in the chapter about tags. If not, some
> comment about possible workarounds, work habits etc would be nice too.
I think you're the first person wha has ever asked this question! I'm
not convinced we need to explain it in the chapter. Maybe a CVS user
might ask, but since chapter 4 is written more as a "introduction to
branching" in general, I'm not sure it's appropriate to talk about
"workarounds". It makes it sound like svn is broken somehow.
> And I would recommend adding to the administration chapter
> some section about managing the large repositories. I would suggest also
> labelling efficiency-risky hints like hot backup in postcommit with some
> kind of warning that this idea is valid for small repositories only.
Ah, good point. I think 'svnadmin dump' is more appropriate as a
post-commit hook, since it really can do incremental backups. I've
always thought of 'svnadmin hotcopy' as more of a once-a-day or
once-a-week sort of thing, to be run by a cron job. But I didn't write
that chapter, I'll defer to cmpilato, and see if he wants to cogitate on
your point.
> I would never tell that 'you can reorganize your repo
> directory structure if you like'. What about all those clients who
> checked out their copy of some modules? That's fine that subversion
> allows to version directory operations but any real practice should
> recommend being very conservative with repository reorganization.
The book assumes that the reader has some degree of common sense. If an
admin decides to rearrange every directory in the repository, presumably
they're doing this *with* their users' knowledge and approval, not on a
whim. I don't think the book needs to enumerate obviously bad policy
decisions and warn people not to do them. The book is about how to
administer Subversion, not how to be an administrator in general. :-)
>
> By the way: the book does not tell what will happen in such a case:
> (playerA) svn checkout <url>/some/module
> (playerB) svn move some/module other/thing
> (playerA) svn commit some/module
> I guess some conflict will arise. How can it be resolved?
It can't be resolved. One user deleted the other user's working copy.
Player A is going to get a big fat error about how '/some/module' no
longer exists.
CVS really only deals with textual conflicts, but SVN opens the doors to
'tree' conflicts as well. Again, the book doesn't try to enumerate
every possible tree conflict, mainly because it's pretty obvious when it
happens, and also because future versions of SVN may get smarter and
smarter about resolving them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 19 03:39:38 2004