[Kolab-devel] topgit-equivalent for hg (was: Re: Poll: Kolab server switching to Mercurial SCM?)

[Gunnar Wrobel]

Hi Thomas!

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

> New subject to keep the poll thread cleaner ...
>
> * wrobel at pardus.de <wrobel at pardus.de> [20100225 22:43]:
>> And if you find anything within git which you cannot find in mercurial,
>> go nag Thomas. He'll probably tell you how to do it in a nicer way in hg.
>>
>> Though... I still don't know how to get something like topgit
>> (http://repo.or.cz/w/topgit.git) in hg. Thomas? ;)
>
> I don't know exactly how to use topgit, but on a first glance it
> seemed more complicated to me than using Mercurial Queues (mq).

In a way yes. The work flow is more complex as the situation it  
handles is more difficult. But it actually does not have that many  
commands. So after a few rounds of initial patch queue management with  
topgit I would say it is not difficult to use.

> Of course this might be due to the added feature of dependency tracking
> of patches.
>
> mq patch queues can be easily tracked as a separate hg repository,

"as a separate hg repository" is the crucial point that topgit avoids.

> no need to learn new commands here. And you can use guards to
> enable/disable certain sets of patches as a simple way of dependency
> tracking.

Been there, done that... guards don't do it. Actually they turn out to  
be quite horrible once your patch queue is a little bit more complex.

>
> Alternatives are the rebase extension (distributed with Mercurial
> like the mq extension) or the tasks extension (currently not
> distributed with Mercurial).
>
> The choice of which extension to use should get easier in the
> future, see
> http://mercurial.selenic.com/wiki/PatchHandlingUnificationRFC

This is a good page! It even lists the hg alternative for topgit:  
pbranch. They have an introduction for it that explains what the  
differences to mq are:  
http://arrenbrecht.ch/mercurial/pbranch/intro.htm.

The wiki page is really nice as it lists pros and cons for the  
different approaches. If hg really gets a joined extension that is  
able to combine most of the pros while avoiding most of the cons: Nice!

Cheers,

Gunnar

>
> Regards,
> Thomas
>
> --
> thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key:  
> 0x5816791A
> Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck,  
> HR B 18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20100227/8ba4e97c/attachment.sig>