Re: [Monotone-devel] tracking upstream

[Timothy Brownawell]

On 09/20/2010 07:23 PM, Brian May wrote:
> 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.

Do you want to push all/most of your company's changes upstream, or only 
specific changes you can identify in advance, or randomly-chosen 
changes? Does work generally *need* to be accepted upstream, or can you 
identify specific things you'd be OK carrying in a branch indefinitely?

> 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.
>
> I have a suspicion that there are no easy answers, and possibly the
> best approach is the last one.

Don't have anything descended from J. Then when you agree with upstream 
that it needs to go away you can suspend it to make the branch 
"disappear" (if it's a uniqueified name that you won't accidentally 
reuse, say with a project number in it; if you reuse it the 
"disappeared" revisions will tag along over netsync), or instruct 
everyone who has it to either 'mtn local kill_certs' on the branch or 
'mtn local kill_revision' on J.

Each separate thing that you (might) want to push upstream should be 
branched directly from upstream (same general idea as 
http://monotone.ca/wiki/DaggyFixes/). If you think you'll drop it if it 
isn't accepted, don't branch anything else off of it until it gets accepted.

If you can't cleanly separate features that way, or don't have enough 
independent features to stay busy without speculative work, then you'll 
have to have work descended from J anyway. In that case you'd have to 
either redo your work or have something similar to 'rebase' depending on 
just how tightly coupled J and the following speculative work were.


--
Timothy

Free public monotone hosting: http://mtn-host.prjek.net