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

Re: Uh ... 'svn copy wc wc' without RA layer?

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-12-01 07:40:47 CET

On Nov 30, 2007 10:04 PM, C. Michael Pilato <cmpilato@collab.net> wrote:
> So ... it could be that it's 1:00am, but I'm having trouble with a scenario.
> See, I went off into mergeinfoless-copies land thinking that one benefit of
> this (besides general correctness) was that 'svn copy wc wc' would no longer
> need the RA layer. We'd just set empty mergeinfo if the copy source didn't
> have mergeinfo.
> But now I'm thinking about this, and I'm wondering how we know the copy
> source have mergeinfo. Don't we have to ask the RA layer about this? If we
> don't, and the mergeinfo for the copy source lives in some parent directory
> we don't have checked out, won't we effectively lose all that mergeinfo on
> the copy target when we set svn:mergeinfo=''?
> Please tell me I'm underthinking this.

Yeah, it's my understanding that this is the core problem here, and
why it does ask the RA layer now. I think the current proposed
situation involves somehow marking the copied item as "we need to find
its mergeinfo" and asking the RA layer for the mergeinfo "later" (at
commit time? at the next RA access?) I'm not sure if anyone has
quite figured out how to implement this though. (The other option is
to get a lot more metadata into the wc about whether or not paths have
mergeinfo in the revision that they are checked out in; it seems like
this would require a lot of redundant information (especially because
of severable wcs, etc).)


David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 1 07:40:56 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.