Re: [glob2-devel] changing glob2 cvs-repository to mercurial!

[Kai Antweiler]

> In the idea I'm positive for mercurial if there is people with good
> experience of it.

Joey and Matthew.


> - Can we have different versions (i.e. the ones in distributions) or do we 
> all 
> need to keep the latest version (i.e. compile from source)

Yes, we can have different versions.
But when you upgrade from versions <=0.9.1 to >=0.9.2 you will
not be able to operate on your local repository.  I don't know
if there is a conversion script.  But you could use the old mercurial
with "hg serve" on the old repository.  And clone it (that is the word
for copy repository with mercurial) with the new mercurial.

Take a look at the upgrade notes:
 http://www.selenic.com/mercurial/wiki/index.cgi/UpgradeNotes

The big distributions all have versions 0.9.1 or 0.9.3.
 http://www.selenic.com/mercurial/wiki/index.cgi/BinaryPackages


> - Could you setup a test repository with a dump from latest CVS so we could 
> test it, let's say, for a week?

The repository I already have, but no one except me can access it.
But I could upload it (7.4mb) on the glob2 webpage.
(how do I do this?)
Then everyone can play around with it.
But to test mercurial that way, we wouldn't need glob2.
Every other repository would be as good (or better when it is small).

btw:  The reason the git repository was small, was that I didn't check
      out.  Strangely I have to check out recent changes in git to update
      the archive mercurial archive.



Here is the mercurial tutorial:
 http://www.selenic.com/mercurial/wiki/index.cgi/TutorialMerge


Basic steps are:

create "~/.hgrc"
it will look like that:
  [ui]
  username = nct
  merge = xemacs-merge.sh

for the merge command have a look at:
 http://www.selenic.com/mercurial/wiki/index.cgi/MergeProgram

get the repository from a remote host:
 hg clone <repository> <local repository>
or get a special revision - like HEAD:
 hg clone -r <tagname> <repository> <local repository>

make yourself one or more copies to work in:
 hg clone <local repository> <bugfix>
 hg clone <local repository> <new feature>
 ...
Every other hg command will be made inside an repository.
 cd <new feature>
Now implement your changes.
Then commit:
 hg commit -m "ALL files I changed will be checked in the <new feature> 
reporsitory"
Other things you might want before commiting: add, remove or rename files.
Look it up:
 hg help
 hg help add
 ...

When you want to upload the changes.  You should do it indirect.
That way you can handle conflicts better.

Change into the initial local director.
 cd ..; cd <local repository>
Get the latest from the <remote repository>
 hg pull -r <tagname> <remote repository>
If something was pulled, update your working directory:
    hg update
  Get back into your other repository:
    cd ..; ch <new feature>
  Get the updates that came from the <remote repository>
    hg pull <local repository>
  Update the directory (check out):
    hg update
    (Sometimes you might need to force this: hg update -C)
  And merge:
    hg merge
  If necessary your merge program you set up at the beginning
  (the ~/.hgrc step)
  will be started, and you have to resolve conflicts.
  Now commit the merged files.
    hg commit -m "resolved conflicts in ..."

You now might want to give your changeset a name:
 hg tag <tagname>
And push it to the remote repository:
 hg push -r <tagname> <remote repository>

Don't use "push -f"!
Done!


Mecurial suggests to have have one incoming, one outgoing and several
development repositories on a local computer:
http://www.selenic.com/mercurial/wiki/index.cgi/FAQ#head-c41d2c1623f62f7e23b7e5737497f2127b248fa7



A really useful command is "hg rollback" which will undo the last
change in your repository (caused by commit or push or pull from
somewhere else).
When you quit your merge program accidentally, or didn't configure ~/.hgrc
correct you will be happy that you have rollback.
But if your last change was a remote pull, you will have to download the
same data again. 
This is the reason why I pulled the <remote repository> to the
<local repository> before pulling it to <new feature>.

There is a command "hg recover" that haven't tried yet.


Also useful:
hg log: shows the history that is the relation ship between the changesets.
        (there are also graphical tools for this - I think.)
hg heads: shows which revisions might couse conflicts.
hg tags: shows the tags in the repository.
hg help: of course
hg revert: will overwrite your directory or file with a specified revision.
hg status: shows which files in the directory differ from the last revision.
           (the name of the last revision is always "tip")
hg diff: shows how files in the directory differ from tip.



Don't commit via email, when not necessary!
This is communication in just one direction.  Therefore your mercurial
won't know which revisions the receptor needs to have a complete
history of the files.  And bad history leads to bad merging.

-- 
Kai Antweiler