monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] tracking upstream


From: Thomas Keller
Subject: Re: [Monotone-devel] tracking upstream
Date: Tue, 21 Sep 2010 10:15:40 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Lightning/1.0b2pre Thunderbird/3.0.6

Am 21.09.2010 02:23, schrieb Brian May:
> Hello,
> 
> I asked a similar question on my local mailing list concerning git.
> Just wondered what perspective I would get here, in particular with
> monotone people. I think similar issues apply in both cases.
> 
> Lets say I am tracking an upstream project. As I am working for a
> company, not myself individually, I have
> to share my changes with other people working in the same company. At
> the same time I want to push the changes upstream.
> 
> A - B - C
> 
> I have revision C, I then make my change J, while upstream makes D, E, F:
> 
> A - B - C - D - E - F
>              \ - J
> 
> This is simple if upstream likes my changes, they will merge them, and we 
> have:
> 
> A - B - C - D - E - F - G
>              \ - J        -/
> 
> And everyone will be on revision G, the result of the merge.
> 
> However, what happens if upstream reject my changes? They don't like
> them. Lets assume they have good reason for rejecting the changes and
> I agree with them. What do I do? I could revert my changes and in
> commit K:
> 
> A - B - C - D - E - F
>              \ - J - K
> 
> However, even though F and K are now a NOP, I am still on a different
> branch to upstream. If I try to get changes from upstream, they will
> get merged into my tree. If I try to push changes to upstream, they
> will get J and K again too - although this is a NOP - it complicates
> the history of the upstream repository, and some people are fussy
> about such things. Plus the person doing the merge has to be convinced
> that it really is a NOP.
> 
> So another thought is to kill off my branch, and go back to working from F.
> 
> Unfortunately, this needs to be done to all my users too, and any
> changes they made would have to get reapplied under F.
> 
> Just curious what to do for this situation.

Instead of disapproving J with K one could also try to suspend J and
branch off on one of its parents. I have to admit though that I'm unsure
if monotone keeps the suspended branch and its revision(s) in your local
database only or if they would be transferred to other nodes still,
leading to the similar / unwanted side effect that people might see the
unwanted change (if they decide to take a close look).

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]