Nik Clayton writes:
> Peter Lundblad wrote:
> > A more sophisticated solution would be to Skip this target, leaving it
> > as is and possibly warn the user at the end of the operation that not
> > all targets were processed correctly and that the operation needs to
> > be restarted after the conflict is rresolved.
>
> When you say "restarted", do you mean that the user should be able to run
> the same "svn merge" command and have it do the right thing?
>
Yup, that's the whole point of it.
> I imagine it won't, because it will try and merge in the changes that have
> already been merged in to the files that weren't in conflict. Generating
> conflicts in those files instead.
>
Yes, without merge tracking;) Note that the problem would exist
anyway (without merge tracking) because files could be merged before
the conflict was detected.
> If it's going to behave like that I'd rather it didn't. How much effort
> would it be for "svn merge" to scan the working copy first (or those files
> in the working copy that will be affected by the merge), checking for any
> files that are marked as conflicted, and refuse to merge anything if any
> files are in conflict.
>
It would be possible to scan all files/dirs for conflicts, but I think
that's a bit restrictive and I don't want to introduce this whole-tree
scan (even if it is in memory) for this case that should be rather
uncommon.
To scan only affected files before merging would mean that we have to
delay any merging until all diff data is received from the RA layer
witch hurts streaminess.
thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 24 21:40:17 2007