On Friday, August 9, 2002, at 01:09 PM, Karl Fogel wrote:
> Philip Martin <philip@codematters.co.uk> writes:
>> This is what Will wrote:
>>
>>> There is one detail that I think is important: If merge copies a
>>> directory that didn't exist in revA (ie the dir was added with
>>> history) then you want to add the merge property to each file
>>> individually. This does not affect the time complexity as all those
>>> files are being copied into your working copy anyway.
>>
>> The files get copied into the working copy, but they will show up as
>> status copied-with-history and unmodified, so only the parent needs to
>> be committed. If we set svn:merge on the files then the files will
>> need to be committed as well.
>
> Oh dear, yes. We should only set the property on the directory that
> was copied... But of course, that loses some of the usefulness of
> having the property at all, for example if we're in a subtree of that
> directory later and need to retrieve merge history...
>
> Which, now that I think about it, is what led me to the long-ago
> conclusion that this problem is not simple. William, thoughts?
I see the issue.
- If you just set it on the top level dir, then you lose the info on
sub-trees. Bad.
- Some form of inheritable properties might be possible, but would be
tricky.
- If you set it on each file then you have to make an individual copy of
each file on the server (you are already making these copies in the
wc) - that copy will be stored as a diff and will have a compact
representation.
I think my original proposal is reasonable. The (slightly) inefficient
part is if you create a large subdir on a branch and then merge it into
another line of dev. In this case things are still not that
inefficient. The content diffs will all be zero length - In effect this
is just storing a node with the svn:merge property for each file. This
is exactly the information you need to store for each file. And this
use case doesn't often happen with large trees anyway.
later,
\x/ill :-}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 9 21:15:08 2002