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

Re: Storing Copied-To info (was: Tree conflicts - thoughts on use cases, merging, and tests)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 21 Mar 2008 09:46:55 -0400

Stefan Sperling wrote:
> On Sat, Mar 22, 2008 at 01:37:12AM +1300, Talden wrote:
>> Note that this probably doesn't make looking for copied-to information
>> cheap, but I think that for many use-cases it will make it cheaper.
> I'd like to see concrete use cases to support a copied-to implementation.
> As stated in another mail in the thread this one has spawn off from,
> I've implemented this once for a client, using properties to store the
> copied-to info (which isn't a good design but works as a proof-of-concept).
> The use case this was going to support was "given fix for a bug, how I can
> find out on which branches this fix has been applied to already?".
> This use case is invalid IHMO because it can be answered more effectively
> by an issue tracker than Subversion itself. The client even ended up not
> using the code.
> Do you have other use cases that would benefit from having copied-to
> information available?

As noted, one admittedly superficial use-case for the ability to trace
forward in an item's history is revision graphing scenarios.

But I actually question the conclusion you provide for your own use-case.
Yes, an issue tracker can tell you which branches have had a bugfix applied.
  But that's rather dependent on your processes involving a tracker, and on
human ability to keep said tracker up to date, and must be cross-referenced
with the version control system anyway to answer the similar question, "In
which branches has this bugfix *not* been applied?"

Note that I'm talking about forward tracing in general, not copy-to. That
stems from an awareness of our backends. That is, if we had a general
successor link from a node-revision to all its successors, "copy to" is a
subset of those relationship (namely, the ones where the successor has a
"copy from" the original node).

I began work some time ago on successor link support on a branch with a
related name (fs-successor-ids, perhaps?). I don't recall the status of
that code -- probably something like "BDB stores it, but you can't use it;
FSFS lacks a design altogether."

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-03-21 14:47:06 CET

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