[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
From: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] resolving name conflicts; file suturing vs drop |
Date: |
Mon, 05 May 2008 06:57:54 -0400 |
User-agent: |
Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1 (windows-nt) |
Ludovic Brenta <address@hidden> writes:
> I have a database where I replicate, via tailor, a Subversion repository in a
> "vendor" branch. In the same database I have my development branch where I do
> all my work. 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.
> The problem takes place when tailor next updates the vendor branch in the
> monotone database. At that point, the file "foo" appears to have been created
> independently in both branches, so I get non-content conflicts. The way I
> resolve them is clunky:
>
> $ cd ~src/tailor/vendor # this is the monotone checkout that tailor maintains
> $ mtn rm foo
> $ mtn propagate development vendor
> $ mtn update
Right. I'm looking for a better way to solve this.
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.
So maybe some variant of 'explicit_merge'.
> 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.
--
-- Stephe
- [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/04
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Ludovic Brenta, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Thomas Moschny, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Markus Schiltknecht, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop,
Stephen Leake <=
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Ludovic Brenta, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Ludovic Brenta, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, William Uther, 2008/05/05
- Re: [Monotone-devel] resolving name conflicts; file suturing vs drop, Stephen Leake, 2008/05/05