preliminary guide to Mercurial via workflows

[Arne Babenhauserheide]

Am Donnerstag 30 April 2009 15:26:32 schrieb David I.:
> First comment is: Good Work! There is a lot of good info here. My
>
> comments are:
...
> I would like to see a typical workflow of using hg resolve. Having never
> resolved conflicts with HG, but many times with CVS, I start getting
> nervous here...

I added a section at "Fixing errors in earlier revisions": 

------ ------ ------ ------ ------ ------ 
$ hg merge

If there are conflicts use "hg resolve" - that's also what merge tells you to 
do in case of conflicts. 

First list the files with conflicts: 

$ hg resolve --list

Then resolve them one by one. "resolve" attempts the merge again: 

$ hg resolve conflicting_file
(fix it by hand, if necessary)

Mark the fixed file as resolved: 

$ hg resolve --mark conflicting_file

Commit the merge, as soon as you resolved all conflicts. This step is also 
necessary if there were no conflicts! 

$ hg commit

At this point, your fix is merged with all your other work, and you can just 
go on coding. Additionally the history shows clearly where you fixed the bug, 
so you'll always be able to check where the bug was. 

Note: Most merges will just work. You only need "resolve", when "merge" 
complains. 
------ ------ ------ ------ ------ ------ 

> This is the first time you have introduced the concept of the .hg
> directory. You may want link to a more detailed discussion at this
> point.

You're definitely right - people might want to know how it works :) . 

Do you have a nice URL I can link to? 

> > repository, to where you "push" changes instead of pulling them.
>
> As a corporate developer, it is more natural to me to think of setting
> up a central repository on a server somewhere. We already have that
> central server anyway. I prefer to start there, but maybe your target
> audience is non-corporate developers here?

The target audience are people who are new to version control - or at least 
new to DVCS. 

But the main reason for starting with "hg serve" is to introduce the 
integrated webserver very early, since you can also use "hg serve" to showcase 
your work, and many people said that "serve" is an instant salesman for them 
:) 

> > ==== Using a shared repository ====
...
> Again, "central server" for corporate development doesn't mean going to
> BitBucket. May want to mention that you can use a central server you
> already have available, or if you don't have one, go to BitBucket. That
> covers both audiences.

How about this: 

------ ------ ------ ------ ------ ------ 
By default "hg serve" doesn't allow pushing, since that would be a major 
security hole. You can allow pushing in the server, but that's no solution 
when you live in different timezones, so we'll go with another approach here: 
Using a shared repository, either on an existing shared server or on 
BitBucket. Doing so has a bit higher starting cost and takes a bit longer to 
explain, but it's well worth the effort spent. 

If you want to use an existing shared server, you can use "serve" there and 
[allow pushing](). Also there are some other nice ways to allow [pushing to a 
Mercurial repository](), including simply [pushing via SSH](). 

Otherwise you first need to setup a BitBucket Account. 
------ ------ ------ ------ ------ ------ 

 
> I suggest moving all the BitBucket specific setup and usage to another
> document. You could also mention the SSH connection types as an
> alternative and give https & ssh URL examples below

I want to enable people to start working directly with the information from 
the guide. Especially for free projects, BitBucket is the easiest way to get 
started. That's why (for me) it's the right thing from the perspective of the 
free software community (as I understand it). 

Also I want to include the BitBucket setup information as a way to help 
BitBucket. They donated the design for the site by hiring a designer, and I 
want to give something back. 

And I use BitBucket myself, and it works great. 

I now added a link to the SSH guide. That way I don't need to duplicate the 
guide from BitBucket :) 

> > Publish your changes:
> >
> > $ hg push https://bitbucket.org/ArneBab/1w6/
>
> How about adding an ssh examples too?

I'm not perfectly sure about that. 

We are no longer at the very beginning of the guide, so a bit more complex 
information may be OK, but at the same time I want to keep it at one (best or 
easiest and good) solution per problem - and notes which contain pointers to 
different approaches. 

And explaining how to create and upload your public key is out of the scope of 
this guide, I think. BitBucket already does that quite well, so I linked to 
their guide on SSH :)  

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
              http://infinite-hands.draketo.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://selenic.com/pipermail/mercurial/attachments/20090501/835794a8/attachment.pgp