Though the behaviour may be the same in both cases, the example that you
give is not quite the same as my situation. I'm renaming an ancestor
directory common to both the trunk and branches directory (two levels
up), not the "branches" directory itself. Here is the scenario:
Assume that we start with the following repository tree:
svn list --recursive http://localhost/subversion/project
Revision 0:
project1/subsystemA/branches
project1/subsystemA/trunk
project1/subsystemB/branches
project1/subsystemB/trunk
Create branch1 in subsystemA:
svn copy http://localhost/subversion/project/project1/subsystemA/trunk
http://localhost/subversion/project/project1/subsystemA/branches/branch1
svn list --recursive http://localhost/subversion/project
Revision 1:
project1/subsystemA/branches project1/subsystemA/branches/branch1
project1/subsystemA/trunk
project1/subsystemB/branches
project1/subsystemB/trunk
Now rename project1 to project2 (directly in the repository):
svn move http://localhost/subversion/project/project1/
http://localhost/subversion/project/project2
svn list --recursive http://localhost/subversion/project
Revision 2:
project2/subsystemA/branches project2/subsystemA/branches/branch1
project2/subsystemA/trunk
project2/subsystemB/branches
project2/subsystemB/trunk
Display the log on branch1:
svn log --verbose --stop-on-copy
http://localhost/subversion/project/project2/subsystemA/branches/branch1
Though I expected (or intended) to see revision 1 (the branch point) in
the log, the log instead stops at revision 2 because we renamed ancestor
directory project1 to project2 (a delete and copy operation).
Derek
-----Original Message-----
From: cmpilato@localhost.localdomain
[mailto:cmpilato@localhost.localdomain] On Behalf Of C. Michael Pilato
Sent: March 29, 2004 9:53 AM
To: Derek Mahar
Cc: Subversion Users
Subject: Re: Determining origin of branch
"Derek Mahar" <DMahar@penson.ca> writes:
> Yes, I agree, this was the expected behaviour (i.e. Subversion is
> behaving correctly), but my point is that "svn log --stop-on-copy"
> does not under all conditions return the branch copy revision as the
> user might expect. If the user has done any other copy operation
> since that user created the branch, --stop-on-copy stops at that copy
> point rather than the branch copy point. Though it is the correct
> result, this is probably not the result that the user expected (or, in
> other words, the result that the user wanted).
Can you provide a recipe for this behavior? The --stop-on-copy option
should only apply when the target of the log operation was the thing
that got copied. In other words, if you do:
svn copy trunk branches/foo
...
svn copy trunk/junk branches/foo/junk
...
svn log --stop-on-copy branches/foo
Your log output should continue past the copy of the thing *into* your
branch, and stop with the copy that created your branch. If you've
found an instance where this is not happening correctly, please try to
come up with a reproducible recipe, because that is a bug.
NOTICE: This email contains privileged and confidential information and is intended only for the individual to whom it is addressed. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this transmission by mistake and delete this communication from your system. E-mail transmission cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.
AVIS: Le présent courriel contient des renseignements de nature privilégiée et confidentielle et n’est destiné qu'à la personne à qui il est adressé. Si vous n’êtes pas le destinataire prévu, vous êtes par les présentes avisés que toute diffusion, distribution ou reproduction de cette communication est strictement interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser immédiatement l’expéditeur et le supprimer de votre système. Notez que la transmission de courriel ne peut en aucun cas être considéré comme inviolable ou exempt d’erreur puisque les informations qu’il contient pourraient être interceptés, corrompues, perdues, détruites, arrivées en retard ou incomplètes ou contenir un virus.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 29 18:22:41 2004