On Mon, Feb 05, 2007 at 09:00:10PM -0800, Stuart Marks wrote:
> Excellent discussion. I'm rather distant from OpenSolaris, but I'm studying
> the
> use of Mercurial in our group (Java ME) so I thought I could contribute
> answers
> to some of the questions raised here.
Cool, thanks.
> Danek Duvall wrote:
> >Now, because mercurial doesn't allow you to "hg update" to an unnamed
> >branch
>
> You can update to an unnamed branch or indeed to any previous rev, simply by
> using the command "hg update REV".
Sure. But that then requires that you manually go through the log to find
an appropriate REV. I think that's definitely asking too much of the user.
I don't mind making users think a little about the model, but I do mind
them having to do makework.
> I think it is potentially confusing, since in the typical case, two heads
> represent a conflict that needs to be merged. In this case, "hg merge"
> implicitly merges with the "other" head. With a mainline head and an
> arbitrary
> number of branch heads, it will always force you to name which head you're
> merging with. This is potentially inconvenient and confusing if you have to
> go
> hunting around to figure out which head to merge with.
Yep. A good graphical tool (like hgk / hgview) could be helpful here.
> If you're going to proceed with this approach, you probably should ignore the
> concept of the tip entirely, and convert over to using named branches. For
> the
> "spine" I'd suggest the term "trunk" (but that's because I have Subversion on
> the brain). Then, tell developers always to start with the trunk ("hg update
> -C
> trunk") and to ignore the tip.
Right. Though that's extra work, and inevitably, someone's going to forget
the "-C trunk" and potentially wonder why they screwed their workspace up.
Danek
_______________________________________________
tools-discuss mailing list
[email protected]
