Selon Stephen Leake <[EMAIL PROTECTED]>: > Ludovic Brenta <[EMAIL PROTECTED]> 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. _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel