1.0 approaches

[Stephen Touset]

On Feb 8, 2008, at 12:44 PM, Sean Kelley wrote:
>
> On Feb 7, 2008 11:52 PM, Matt Mackall <mpm at selenic.com> wrote:
>>
>> On Thu, 2008-02-07 at 21:36 -0800, John D. Mitchell wrote:
>>
>> The time for such non-backward-compatible changes has long since  
>> past so
>> there's not much point to this conversation.
>
>
> That is good to hear.  We use named branches for our software
> configuration management of release branches.  I would enjoy seeing
> improvements.
>
> So in our case a Library may have multiple named branches:
>
> default
> rel-2.x
> rel-3.x

Why not do this using clones?

Where I work, we have clone each release for stabilization. Everything  
is in its own folder, and nobody has problems with accidentally making  
commits to a release branch instead of trunk. Last time I looked at  
the Mercurial repo, they follow the same tactic.

> Many of our developers are very used to GIT branching and if there
> were an extension or anything really that could give us what you can
> do with GIT branches, all the better.

Mercurial and Git handle these concepts in very different ways. The  
fact that Git does it one way should not be an automatic argument for  
Mercurial doing the same thing.

-- 
Stephen Touset
stephen at touset.org



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1580 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20080208/065ae90a/attachment.bin