Workflow questions

[Kevin Smith]

Matt Mackall wrote:
> 
> Imagine you have local branches U (upstream) and W (working). Then do:
> 
> cd U
> hg merge upstream  # do a simple sync (no conflicts) from upstream
> 
> cd ..
> mkdir M # merge
> cd M
> hg branch ../W  # branch off of W
> hg merge ../U   # do a merge with potential conflicts
> hg co           # inspect the result
> 
> cd ../W
> 
> hg merge ../W   # do a simple sync of our merge

Ok. That has more moving parts than I would prefer, but looks fine. The 
logic makes sense. The extra layer could be hidden behind a gui, I 
think, to make it appear as a single transaction.

> As for not taking a changeset, that's the famous cherrypicking debate.
> I've made no effort to address it in Mercurial. BitKeeper didn't do
> it, Linus eventually decided this was actually a feature (because it
> kept junk out of the tree history), and I tend to agree. If you need
> to do this, it's probably best done with some combination of export
> and import right now.

Hm. I thought the "feature" Linus liked was that he couldn't take *part 
of* a changeset. Clearly he does choose which changesets to accept into 
his tree and which not to. I guess the distinction is that he doesn't 
use a "merge" command to do so.

So if someone exports patch files and sends them to me individually, I 
can accept or reject them individually. But if I use hg merge to pull 
from their repo, I must take everything. Interesting. I'll have to 
overhaul my workflow to compensate for this.

On this project I'm thinking of, my current (CVS) method is that I allow 
other folks to put crap into the master repo, but sometimes I choose not 
to pull it into my local system. Later, after they push fixes into the 
master, I'll take the fixed version. I guess with hg, I'll need to 
either take the crap, or somehow prevent it from getting into the master 
in the first place.

So if someone wants to contribute to my project, it actually doesn't 
help at all if they publish their repo online? Because I can't merge 
from it anyway--I need them to export their individual patches so I can 
individually import them? Hmmmm. I feel like I'm still missing something.

> There will eventually be a 'push' command that does ssh.

On the project I'm thinking of, one developer uses MS Windows, so I 
doubt that would work for him. But he's inside the lan (or vpn) with the 
server, so I think he can just smart-copy his stuff from his workstation 
to the server. If we have MS Windows developers outside the lan, I'm not 
sure what they would do.

> I personally rsync directly from my laptop repo to the master repo.

That's what I did on a different project, with darcs, when I was the 
project dictator. On the project I described above, there are multiple, 
equal contributors.

> But merging into upstream is a fundamentally serial process. The
> pull-only model is nice in this regard as the "maintainer" simply
> pulls each queued submitter's tree in turn (and resolves the conflicts). No
> one has to sit waiting for their turn on the commit queue to attempt
> to merge.

Agreed. I definitely prefer the "nothing but pulls" model, so I'll try 
to make it work.

This kind of workflow stuff is underdocumented for almost all the free 
distributed SCM's. Eventually someone will write up a nice tutorial and 
"best practices" document, and all the projects will benefit. It's 
something I may do at some point, if nobody else does it first.

Thanks!

Kevin