Any requirements to post a ("DVCS branching with Mercurial") presentation in http://mercurial.selenic.com/wiki/Presentations?

[Martin Geisler]

Colin Caughie <c.caughie at gmail.com> writes:

> On 1/6/2013 4:22 PM, dukeofgaming wrote:
>
>>     Thanks for your feedback.
>>
>>     Personally, I think "clone to branch" is silly, because all you
>>     are doing is copying your whole project again... something you
>>     used to do when you were still to newbie at programming to know
>>     what version control was. But then again as Matt says, it is
>>     important for didactic purposes (if I interpreted him correctly).
>
> Surely this is missing the whole point of DVCS. Yes you're making
> another copy of the project, but you're also copying the history,
> which is represented in such a way that changes in one clone can
> quickly and easily be pulled and merged into another. The newbie who
> just makes a copy of his source tree can't do that.

Very true -- local clones are definitely not silly. They can become
unpractical, but that depends on the project size.

> As Matt says, every time you clone a project (which you have to do in
> order to work on it) and commit a new change, you're doing "clone to
> branch"; it doesn't make much sense to call something silly that you
> have to do every time you use the system. Moreover, as I already
> explained there are some good, practical reasons why you might want to
> work on different branches in separate clones, and there is absolutely
> no downside to doing so, so I'm not sure why you're discouraging this
> in a presentation you intend to make public.

My impression is that people tend to prefer fewer clones after they get
used to the idea of multiple lines of development in a single clone.
Also, when the projects become big (gigabytes), people start hesitating
before creating a new checkout.

You're right that local clones are great for maintaining the overview,
and they are necessary if you want to maintain several independent
working copies (modulo the share extension).

Keeping build artifacts around can also be beneficial -- though I've
more often heard people complain about the initial checkout and build
time associated with a new local clone. With an in-repo branch there's
no checkout time and with a working build tool you avoid rebuilding more
than you have to. Of course you pay for that by rebuilding more often
when you switch branches... it's a tradeoff :)

-- 
Martin Geisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20130107/a9bd0b55/attachment.asc>