Migration

[Lionel]

Nicolas,

I forgot to say you should not only give a try to TortoiseHG but also to the
HG plugins available for various IDE (we're using VisualHG for Visual
Studio).

-----Message d'origine-----
De : mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com] De
la part de Tom Anderson
Envoyé : mardi 27 septembre 2011 11:33
À : nicolasp at aaton.com
Cc : mercurial at selenic.com
Objet : Re: Migration

On 27 September 2011 09:01, Nicolas Pinault <nicolasp at aaton.com> wrote:

>> Globally yes, this is a way to start. But it is generally advised to
>> connect to the central repository (the "server") via http rather than via
a shared
>> drive. The http server can be either Apache or IIS - the setup is quite
>> easy and well explained on Mercurial site.
>
> Ok. I'll have a look at it.

Even better than HTTP would be SSH, if you can support that. If your
server already supports SSH (by being a unix machine), then there is
no setup to do, and i believe it is more efficient than HTTP.

>> Just in case of, as you didn't mention it, if you come from svn to
>> Mercurial (as we did), the main point you have to remember is that HG
works in 2
>> stages, commit/update between your working directory (on your PC) and
your
>> local repository (on your PC), and push/pull between your local
repository
>> and the server repository.
>
> I've noticed the "two steps" workflow. I have already with it. It is a bit
> disapointing at first but I can easily see the advantages around it.

I suggest that you should think of 'hg push' being the equivalent of
'svn commit', and 'hg commit' as being a sort of 'save' on steroids.

Just as you are already in the habit of saving your work every few
moments, you should be in the habit of committing often. Perhaps as
often as every time you make a new unit test pass; perhaps less often,
whenever you complete some identifiable slice of work. Because
committing is local, all this is doing is storing your work safely in
your local repository - establishing a sort of checkpoint. You are
still in control of what gets shared with the rest of the team, and
when, because that is done by pushing.

>> In a whole, Mercurial is a little more complex than svn but it is so
>> powerful and easy to use after some time that nobody in my team would
>> never switch back to svn.
>
> I also noticed the slightly higher workflow complexity of Mecurial over
svn.
> But I think it is worth the effort.

I agree. Having local commits is incredibly useful. Local commits are
to programming as pitons are to mountaineering. Without them, your
only safety line is attached to your colleagues, who may or may not be
able to save you if you fall; if they don't, you will tumble all the
way back to your camp, at the last checkin. With them, you have a
trail of rock-solid points closely spaced behind you to which you can
retreat if you get in trouble.

The improved merging is also very nice, of course. I do not have a
mountaineering metaphor for that.

>> Two very good resources to learn HG:
>> - HG's wiki (and notably http://mercurial.selenic.com/wiki/Tutorial )
>> - HG's handbook  http://hgbook.red-bean.com/read/

Note that a new version of the Definitive Guide is currently being written:

https://bitbucket.org/natosha_bard/hgbook

Also, the 'hg help' text itself is really very good.

tom

-- 
Tom Anderson         |                e2x Ltd, 1 Norton Folgate, London E1
6DB
(e) tom at e2x.co.uk    |    (m) +44 (7960) 989794    |    (f) +44 (20) 7100
3749
_______________________________________________
Mercurial mailing list
Mercurial at selenic.com
http://selenic.com/mailman/listinfo/mercurial