Re: [Monotone-devel] resolving name conflicts; file suturing vs drop

[Ludovic Brenta]

Selon Stephen Leake <address@hidden>:

> Ludovic Brenta <address@hidden> writes:
[snip]
>> Occasionally, I add a file in my development branch. In order
>> to propagate changes to the upstream Subversion repo, I apply patches and
>> commit  manually in Subversion, e.g.
>>
>> $ mtn diff -r h:vendor -r h:development > /tmp/f.diff
>> $ svn checkout svm+ssh://svn.upstream.org/trunk
>> $ cd trunk
>> $ patch -p0 < /tmp/f.diff
>> $ svn add foo
>> $ svn commit -m "merge from development branch"
> 
> I gather that tailor only provides a one-way link between the svn and
> mtn repositories? Otherwise you could use tailor to push the new file
> to svn.

You are correct; I use tailor in only one direction. However, even if I would
use tailor in the other direction, the problem would remain. Tailor would do no
more than "rsync the Subversion working space; svn add $(new_files); svn
commit".
 
> Right. I'm looking for a better way to solve this.

I really appreciate that you're taking the time to do this. Such a feature would
be very valuable to me.

> I've proposed a rather elaborate method using the output of 'automate
> show_conflicts', editing the resulting file, and commiting with 'merge
> --resolve_conflicts'. For the case where there is only one conflict,
> or all the conflicts can be resolved in the same way, we could have a
> shortcut:
> 
> 'merge --resolve_conflict="resolve_content_ws"'
> 
> Hmm. I guess in your case, since you are doing 'propagate', that would
> really have to be:
> 
> 'propagate development vendor --resolve_conflict="resolve_content_ws"'
> 
> Although then "ws" is ambiguous; it could be either development or
> vendor. Sigh.

Not really. In my case, ideally I should only propagate one way (from vendor to
development). So, when propagating from vendor to development, all I really
need is a way to resolve all non-content conflicts by ignoring the changes made
in the vendor branch.

For content merges, emacs allows to use "default-A" or "default-B". If the same
was available for non-content conflicts I would be happy.

> So maybe some variant of 'explicit_merge'.

I tried merge_into_workspace and that wasn't entirely satisfactory. I ended up
with the result I wanted, but at the cost of really ugly hacks like "mtn cat -r
some_previous_revision foo > foo; mtn add foo".

> > In essence I'm mucking around behind tailor's back. 
> 
> Yes. So the other solution is to make tailor provide a two-way link
> between svn and mtn.

Like I said, it's not clear to me that that would solve anything. Plus, I want
to write into the upstream repository manually rather than automatically.

Thanks for your help on non-content merges!

-- 
Ludovic Brenta.