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

dukeofgaming dukeofgaming at gmail.com
Mon Jan 7 00:22:37 UTC 2013


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).

I will add a bit about using phases for private branches. Which isn't
something quite necessary, but then again, some do appear to have the need
to keep some of their work private.

Thanks,

David


On Thu, Jan 3, 2013 at 12:17 AM, Matt Mackall <mpm at selenic.com> wrote:

> On Wed, 2013-01-02 at 21:48 -0800, Colin Caughie wrote:
> > On 01/02/2013 5:15 PM, Matt Mackall wrote:
> > > On Wed, 2013-01-02 at 15:25 -0800, Colin Caughie wrote:
> > >> On 12/31/2012 1:11 PM, dukeofgaming wrote:
> > >>
> > >>> On Sun, Dec 30, 2012 at 9:19 PM, Kevin Bullock <kbullock
> > >>> +mercurial at ringworld.org> wrote:
> > >>>          On 28 Dec 2012, at 3:00 PM, dukeofgaming wrote:
> > >>>          >
> > >>>          >
> > >>>          > - Do these presentations have to be run by anyone in order
> > >>>          > to be posted or can I just edit the wiki and link to my
> > >>>          > presentation
> > >>>
> > >>>
> > >>>          Feel free to add it yourself.
> > >>>
> > >>>
> > >>> Cool
> > >>>
> > >>>
> > >>>          > - What do you think of it? (if you can spare the time, it
> > >>>          > would be nice to have the expert's proofreading)
> > >>>
> > >>>
> > >>>          I can't tell, since I don't see a link to the presentation
> > >>>          here. ;)
> > >>>
> > >>>
> > >>> Oh crap, don't you hate it when it happens?, haha:
> > >>>
> > >>>
> > >>> http://www.slideshare.net/dukeofgaming/dvcs-branching-with-mercurial
> > >>>
> > >>>
> > >>>
> > >> This is generally a nice presentation, the one thing I'd dispute is
> > >> referring to the "clone to branch" strategy as "lazy/incorrect". My
> > >> understanding is that branching by cloning is not only correct but the
> > >> default way to branch in Mercurial, and existed long before any of the
> > >> other methods - moreover it's used by the Mercurial devs themselves
> > >> (correct me if I'm wrong).
> > > We switched to using named branches for 1.4 back in 2009.
> > >
> > > But everyone should absolutely understand "clone to branch" first...
> > > because it's conceptually what happens every time you clone and commit:
> > > you're working on a branch of the project that's distinguished only by
> > > its location on your local disk.
> > >
> > I understand that the hg repo uses named branches to distinguish the
> > stable release branch from the new development branch (as far as I can
> > see there are exactly two named branches in the repo, "default" and
> > "stable"), but isn't it also true that individual trusted developers
> > maintain their own clones (i.e. branches) for new feature work, which
> > are then pulled and merged into the "master" repo?
>
> Again.. this is deeply tautological. When you do work _locally_ and
> _disconnected_, which is what you are doing whenever you use _any DVCS_,
> you are creating a private branch. It's private by virtue of being
> local, and a "branch" by virtue of being a "divergent line of
> development" from what anyone else is doing while you're disconnected.
>
> We can put additional markers like bookmarks or named branch labels on
> these private branches, but for most purposes this isn't necessary.
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20130106/65b2b9bf/attachment-0002.html>


More information about the Mercurial mailing list