[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r32998 - trunk/subversion/libsvn_wc

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 10 Sep 2008 16:26:41 +0200

On Wed, Sep 10, 2008 at 06:39:48AM -0700, Greg Stein wrote:
> Well, copies are normally recorded, so that'll still be there.
> ("copied from /some/where, rev RR").
> Are you asking to record that a file was copied *to* elsewhere?

Yes please.

> Not sure about doing that.

The working copy (and repository, but later) should be able to provide
such info on request IMO. What higher layers do with the information
stored in the working copy is a different matter.

AFAIK the helper tool which will be presented at the following talk at
Subconf makes use of copied-to information gathered from 'svn log'
(and yes, that is slow!):

I don't know whether they are only using it for rename tracking though,
in which case your current design would probably suffice.

But also, think about e.g. what Mercurial does when receiving a diff for
a file which was copied -- it applies the diff to all copies (and
hence renamed files) as well as the original.
I don't know whether this behaviour is good or bad (I believe it depends
on what the user wants), but it would be nice if we could somehow include
support for this in wc-ng, at least at the basic data structure level.

Another application for copied-to information is when graphing the
history of a single file forwards in time. It is very cumbersome having
follow all branches' HEADS in the repository backwards in time
to the root in order to find out on which branches a given file is
or was present.

So another related use case is asking "on which branches did we already
apply the bug fix for file foo.c?" Subversion currently cannot answer this
question in a straightforward way.

Note that I even wrote a patch once which added "copied-to" properties
containing "rev:destination_path" tuples for every copy operation made
on a file. svnadmin was hacked to crawl the repo and create such properties
everywhere in the repository, providing a "reverse lookup" of the
copy-from information already present.
After that, looking up on which branches a given file on trunk was present
was a simple O(1) operation. That patch was never submitted here, and was
never even used by the client who ordered it (for reasons unknown to me).
But it was working, and there was demand for it.

So yeah, I'd really like to see copied-to info in wc-ng. We could
later have this information propagate to the repository-side as well.

I believe, and please correct me if I'm wrong on this one, that copied-to
info was originally deemed redundant and left out to keep the design
simple and lean. However, I think that this was a wrong decision, because
having to compute this information at run-time can be a burden.
It should be comparatively trivial to record copied-to information
at the time copies are made, though.

Even if we don't make use of this information right away, it may come
in handy in the future.


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-10 16:26:28 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.