> > 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.
First some reasoning: currently I use sth like 'cvs log -r oldtag
-r newtag' while preparing release notes for the new version of
this or that application. Aggregated change descriptions are
very handy while writing changes description for the client. And
I think I will have similar need whatever version control I use
in future...
If I understand you correctly, in Subversion similar question is
far harder to ask. Running 'svn log -rX:Y trunkUrl' is easy but
finding what are X and Y seems to be harder - in fact I need to
run svn log for both tags and then search for the last common
entry to find what X is (or is there some easier way?).
So what is the Subversion concept of raporting what has changed
between the two tags?
> > 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. :-)
In case Subversion gets momentum, your book will likely be what
Cederqvist is for CVS - the first and main source of information
for numerous developers and administrators. Therefore I'd
reccomend paying a lot of attention not only to the technical
details but also to the recommended practicies and policies...
Especially considering the fact that Subversion allows a lot of
freedom.
> > 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.
So I'd add some warning about that problem in the chapters about
svn move and svn delete. Plus note how to handle it in case it
happens (svn log to check what happened + svn switch?)
Best regards
PS I'm fairly impressed with the time in which I got response to
my emails and the responses quality.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 19 16:26:17 2004