You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mats Nilsson <ma...@xware.se> on 2002/06/28 10:04:07 UTC

How do I find out the ancestor of svn cp?

Hi

I'd just want to bring up an issue related to issue #690 since I haven't
seen it being discussed. If this is already in the plans please ignore this
post.

The question is simple: how will I be able to use "svn log" to find out the
source (path/revision) of a "svn cp" or a "svn mv"? As of 0.13.1+ (version
2346), "svn log --verbose" only shows the target.

This will become increasingly important when svn is used to implement more
elaborate branching schemes.

Mats





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How do I find out the ancestor of svn cp?

Posted by Ben Collins-Sussman <su...@collab.net>.
"Mats Nilsson" <ma...@xware.se> writes:

> The question is simple: how will I be able to use "svn log" to find out the
> source (path/revision) of a "svn cp" or a "svn mv"? As of 0.13.1+ (version
> 2346), "svn log --verbose" only shows the target.

Huh?  The new repository filesystem now traces back through copy
history.  For example, libsvn_wc/update_editor.c was renamed from
'get_editor.c' in revision 1316:

$ svn log -v update_editor.c
...
rev 1316:  sussman | Tue, 19 Feb 2002 14:34:21 -0600 | 1 line
Changed paths:
   D trunk/subversion/libsvn_wc/get_editor.c
   A trunk/subversion/libsvn_wc/update_editor.c

* update_editor.c:  rename.  No longer 'get_editor.c'
...


Of course, I see your point.  That log output would be more useful if
we could see some information that says "update_editor.c was copied
from (1315, get_editor.c)".  I believe 'svnlook' is doing that right
now, because it's asking dir_delta() for the copy history:


$ svnlook repos rev 1316 diff

Copied: update_editor.c (from rev 1315, trunk/subversion/libsvn_wc/get_editor.c)

Really, I suspect 'svn log -v' should be doing exactly the same thing,
no?  Maybe we should file an issue on this?




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: How do I find out the ancestor of svn cp?

Posted by cm...@collab.net.
"Mats Nilsson" <ma...@xware.se> writes:

> I wrote:
> > The question is simple: how will I be able to use "svn log" to find out
> the
> > source (path/revision) of a "svn cp" or a "svn mv"? As of 0.13.1+ (version
> > 2346), "svn log --verbose" only shows the target.
> 
> More thinking.
> 
> Does the infrastructure for this even exist? Is the ancestor stored
> somewhere?

Yes, it does.  It lives in the `copies' table, which stores, for every
copy operation that occurs, the source path and revision, and the
destination node-revision-id.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

RE: How do I find out the ancestor of svn cp?

Posted by Mats Nilsson <ma...@xware.se>.
I wrote:
> The question is simple: how will I be able to use "svn log" to find out
the
> source (path/revision) of a "svn cp" or a "svn mv"? As of 0.13.1+ (version
> 2346), "svn log --verbose" only shows the target.

More thinking.

Does the infrastructure for this even exist? Is the ancestor stored
somewhere?

I continued thinking that, if not, then "svn log --verbose --show-ancestors"
might be a feature that would come for free implementing the post-1.0
intelligent merging, assuming that automerge would need to have the option
of looking further back in the history than merely that of the current
"branch".

Given that merge history would be stored in properties of directories/files,
I guess so would the record of the initial ancestor. Unless, of course, the
ancestor path/rev is already stored somewhere else.

Anyway, my refined point is that it seems more logical that this information
is represented as a dir/file property than a revision attribute, even if it
could be extracted and presented in a suitable "svn log" record. So is this
case similar to what has already been optimised for issue #690?

Mats






---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org