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

Re: Peg revision question

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 05 Mar 2010 15:49:54 -0500

Mark Phippard wrote:
> On Fri, Mar 5, 2010 at 1:55 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> It's not a new "line of history" of any sense that we typically sling that
>> phrase.
>
> I guess I was thinking that even though this was moved, internally it
> was a copy + delete. So what if it had just been a copy only? We
> would never expect the history from the origin to follow into the copy
> in that scenario (as opposed to just staying in the origin). So I at
> least think it is a related but new line of history from the point of
> copy?

I think we're just using slightly different terminology here, and for me the
word "new" is the part that's not consistent with the way I've been talking
about lines of history for the past so many years. It's not a big deal
though. Yes, a copy introduces some fork in the existing object's
historical lineage. Whether that's a "new line" or a "fork in the existing
line" is today irrelevant -- your concern is what Subversion can and can't,
should and shouldn't do when navigating such artifacts of history.

I actually *would* expect Subversion, when tracing history from the origin,
to follow into any and all copies if asked to do so. If you poll our
customer base, you'll find similar wishlist items, usually of the sort that
sound like "Show me all copies of some_file so I can port a particular bug
fix I just made to those places, too."

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

Received on 2010-03-05 21:50:31 CET

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.