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

Re: Progress of extract and merge non-reflective changes from a reflective rev

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-12-07 02:13:18 CET

On Thu, 06 Dec 2007, Mark Phippard wrote:

> Please see this reply I gave to Folker on dev@
>
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=133357

I responded to this thread as well.

> It seems to me that the path Kamesh has been going down is
> essentially the same one that Folker has been advocating. Perhaps we
> ought to at least try to get the schema change and related code for
> populating it into trunk. I say this because if we ship 1.5 without
> capturing this information it might be hard to go back later and fix
> it should we decide we need it.

Yes, I am also a proponent of this strategy. This will require fixing the
issue #3037 problems turned up by glasser, which deletes (and now, copies)
don't have their mergeinfo index properly updated.

> I am not completely sure why we are so easily pushing off to the
> future what Kamesh has been working on either. Is the issue that the
> remaining work of actually using this new information is the really,
> really hard part with lots of work to do? In the past Kamesh has
> implied he was close to a solution, but I am not sure if he/we have
> changed the solution to be more complicated since then.

When we get the whole-branch-merge branch, and/or Mike's work, into a
state that handles the "safely merge back into trunk, handling mergeinfo"
use case, the priority of issue #2897 drops to the point where it is no
longer a 1.5 blocker. That said, it doesn't mean that we can't include
the fix for issue #2897 in 1.5 if it's completed in time.

  • application/pgp-signature attachment: stored
Received on Fri Dec 7 01:12:30 2007

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.