On Tue, 2004-09-28 at 12:35, Archie Cobbs wrote:
> > One minor comment so far: You're pretty insistent in check_branch_dir()
> > on having a totally clean WC before doing an init or merge operation.
> > Seems to me you could be a teensy bit more forgiving without sacrificing
> > correctness, I am thinking particularly of the case of unversioned files
> > in the WC such as compiled object files. Maybe use the "-q" option in
> > the second invocation of svn stat?
>
> Yes, I did that because the merge will fail if a file that is added
> in the merge also already exists (unversioned) in the branch tree.
> The workaround is to put such files in svn:ignore. However, I agree
> this is pretty conservative behavior, so maybe just letting the merge
> fail and leaving it up to the user to fix is better.
Yeah, I think that's better. Another possibility might be to warn the
user but proceed anyways. Maybe if "svn status" shows dirty files but
"svn status -q" does not? (Hmmm...that's going to take longer though.)
> On the other hand, having outstanding changes to versioned files (as
> opposed to extra, unversioned files) is a much more serious threat to
> the process.. because you could unwittingly "merge" in a change that
> never existed in the head branch. That's much more important to guard
> against.
Yep, that's definitely a case to be avoided.
> Another thought I had is that it would be nice if it could auto-detect
> any "empty" merges, i.e., commits that don't affect the head branch,
> and go ahead and merge them in. Otherwise, they just clutter up the
> list of outstanding merges, obfuscating the non-empty changes; right
> now you have to manually include them in your merge list.
This sounds cool although I am not sure how one would do this cheaply.
> Also, I created a little web page...
>
> http://www.dellroad.org/svnmerge/
>
> Thanks for the suggestions and for testing it out!
You bet. I'll *really* test it out when I have to do a merge for the
first time. :-)
Bruce.
Received on Wed Sep 29 01:05:26 2004