Mercurial Digest, Vol 93, Issue 7
Anton Gogolev
anton.gogolev at gmail.com
Tue Jan 8 08:24:55 UTC 2013
On 07.01.2013, at 22:00, mercurial-request at selenic.com wrote:
> Send Mercurial mailing list submissions to
> mercurial at selenic.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://selenic.com/mailman/listinfo/mercurial
> or, via email, send a message with subject or body 'help' to
> mercurial-request at selenic.com
>
> You can reach the person managing the list at
> mercurial-owner at selenic.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mercurial digest..."
>
>
> Today's Topics:
>
> 1. Re: Any requirements to post a ("DVCS branching with
> Mercurial") presentation in
> http://mercurial.selenic.com/wiki/Presentations? (dukeofgaming)
> 2. Re: Global 2.6 Sprint - London it is, please make your travel
> plans (v)
> 3. Re: Global 2.6 Sprint - London it is, please make your travel
> plans (Pierre-Yves David)
> 4. Re: ANN of new versions of Mercurial (Paul Boddie)
> 5. Re: Any requirements to post a ("DVCS branching with
> Mercurial") presentation in
> http://mercurial.selenic.com/wiki/Presentations? (Colin Caughie)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 6 Jan 2013 18:22:37 -0600
> From: dukeofgaming <dukeofgaming at gmail.com>
> To: Matt Mackall <mpm at selenic.com>
> Cc: "mercurial at selenic.com" <mercurial at selenic.com>
> Subject: Re: Any requirements to post a ("DVCS branching with
> Mercurial") presentation in
> http://mercurial.selenic.com/wiki/Presentations?
> Message-ID:
> <CAFt2z-kW0X-2rZsUfZdWrG9kt+CnUO4_Pq6ye=RETOP3qencJw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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://selenic.com/pipermail/mercurial/attachments/20130106/65b2b9bf/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 7 Jan 2013 02:26:59 -0800 (PST)
> From: v <voldermort at hotmail.com>
> To: mercurial at selenic.com
> Subject: Re: Global 2.6 Sprint - London it is, please make your travel
> plans
> Message-ID: <1357554419541-3996765.post at n3.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
> Consensus merge and issue 883 (renames consume extra space in repository)
> were on the agenda for a previous sprint, but nothing seems to have become
> of then. Were they dropped for lack of interest?
>
>
>
> --
> View this message in context: http://mercurial.808500.n3.nabble.com/Global-2-6-Sprint-London-it-is-please-make-your-travel-plans-tp3996598p3996765.html
> Sent from the General mailing list archive at Nabble.com.
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 7 Jan 2013 11:33:41 +0100
> From: Pierre-Yves David <pierre-yves.david at logilab.fr>
> To: v <voldermort at hotmail.com>
> Cc: mercurial at selenic.com
> Subject: Re: Global 2.6 Sprint - London it is, please make your travel
> plans
> Message-ID: <20130107103341.GA2545 at crater2.logilab.fr>
> Content-Type: text/plain; charset="us-ascii"
>
> On Mon, Jan 07, 2013 at 02:26:59AM -0800, v wrote:
>> Consensus merge and issue 883 (renames consume extra space in repository)
>> were on the agenda for a previous sprint, but nothing seems to have become
>> of then. Were they dropped for lack of interest?
>
> They were discussed during the sprint. But no time were spent do make
> them happen.
>
> If you are interested, consider coming to the sprint and spending time
> on them.
>
> --
> Pierre-Yves David
>
> http://www.logilab.fr/
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 198 bytes
> Desc: Digital signature
> URL: <http://selenic.com/pipermail/mercurial/attachments/20130107/8c894f20/attachment-0001.pgp>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 07 Jan 2013 13:05:23 +0100
> From: Paul Boddie <paul.boddie at biotek.uio.no>
> To: Adrian Klaver <adrian.klaver at gmail.com>
> Cc: "mercurial at selenic.com" <mercurial at selenic.com>
> Subject: Re: ANN of new versions of Mercurial
> Message-ID: <50EABA03.6040808 at biotek.uio.no>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 27/12/12 04:46, Adrian Klaver wrote:
>> On 12/26/2012 01:05 PM, Matt Mackall wrote:
>>> And that's what the goal of announcing the release candidates instead of
>>> the releases is: encourage Earl to be earlier so that his extra
>>> enthusiasm actually helps the project.
>>
>> The fault I see in this is the assumption you can increase the pool of
>> early adopters. I yet to see that happen. There is a fairly fixed
>> proportion of software users that will take the plunge, the rest wait.
>> The early adopters tickle the low hanging bugs. It is not until the
>> final release is made and the pool of users expands do the tough bugs
>> get flushed out. Do not understand why a production release should be
>> hidden. It would seem to be something to be proud of. In any case it
>> is not my project, so I will go along with the program.
>
> Another problem with only announcing release candidates is that people
> may hold off on upgrading because they see various release candidates
> and nothing more and then think that the release has been blocked somehow.
>
> I'd also agree that even with substantial encouragement, most people
> won't even look at prereleases and will only ever stumble across bugs
> when they finally upgrade to a proper release, which I suppose is the
> essence of the "Earl" character. The problem is that most instances of
> Earl will not be in a position to use release candidates, either because
> they are not really allowed to or because they depend on the software
> for their work [*]. And it is precisely the class of bugs associated
> with using the software "in anger" that won't get flushed out just
> through enthusiastic testing, although you can obviously work towards
> better test coverage.
>
> I have to say that it's a bit weird to implicitly claim that Earl's
> enthusiasm doesn't actually help the project. We can all be disappointed
> that Earl didn't give the release candidates a test drive and eliminate
> bugs from an actual release, but having him report bugs is better than
> him and everyone else affected by a particular bug giving up and
> silently using something else.
>
> Paul
>
> [*] When asked to give Ubuntu releases a test to see if the bootloader
> works, to provide an extreme example, I often wonder whether Canonical
> thinks its demographic is a bunch of tinkerers who don't do anything
> more than try out the latest release, as opposed to people using the
> software to do actual work. I also wonder whether they have any testing
> infrastructure to eliminate basic deployment issues at all. There's only
> a limited potential in asking people to bear a significant cost
> (disruption and potential loss of work) in order to save a much lower
> cost to the project.
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 07 Jan 2013 09:30:58 -0800
> From: Colin Caughie <c.caughie at gmail.com>
> To: dukeofgaming <dukeofgaming at gmail.com>
> Cc: "mercurial at selenic.com" <mercurial at selenic.com>
> Subject: Re: Any requirements to post a ("DVCS branching with
> Mercurial") presentation in
> http://mercurial.selenic.com/wiki/Presentations?
> Message-ID: <50EB0652.2000904 at gmail.com>
> Content-Type: text/plain; charset="us-ascii"
>
> An HTML attachment was scrubbed...
> URL: <http://selenic.com/pipermail/mercurial/attachments/20130107/2084695c/attachment-0001.html>
>
> ------------------------------
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>
> End of Mercurial Digest, Vol 93, Issue 7
> ****************************************
More information about the Mercurial
mailing list