On Sat, Mar 22, 2008 at 2:22 AM, Stefan Sperling <stsp_at_elego.de> 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.
I would like Subversion to be able to be authoritative on copy
information. Requiring a side process to capture this information
just begs for human error issues.
> Do you have other use cases that would benefit from having copied-to
> information available?
Though I don't consider it of high value, but I could see someone
asking 'where has this file been copied to' in an obliterate task...
The user would need to know all clones of sensitive information to be
purged to purge those paths as well (and the Obliterate feature could
use this information to do that follow operation more cheaply).
> > Would this be useful in building
> > revision graphs that trace tagging and branching as well as
> > modification?
>
> Yes, I think it would. This is one valid, albeit exotic, use case already.
Tags, Tag collections, branches and branch collections are other
potentially useful pieces of meta-data, combined with copied-to would
make intelligent graph generation much much easier.
I don't see the revision graph as an exotic use-case in a VCS... it is
for Subversion but then that's because support for it sucks.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-22 00:55:49 CET