Random toughs

[Steve Borho]

On Fri, 2007-10-19 at 11:45 +0200, Jonas Pfenniger wrote:
> Hello again,
> 
> these are all notes I have collected on my Hg investigation. Mercurial
> is better (for us) than Git, Darcs, Bzr, BitKeeper and Perforce. The
> context is a two developer shop with future co-workers. We want to use
> it in a more centralized way.
> 
> Please note that I am still a newbie to Mercurial so it is not
> necessary really insightful.
> 
> = integrity
> 
> There are at least two locking/race bugs open in the BTS (#132 and
> #552). RevlogNG seems pretty safe on the principles but I didn't find
> documentation in cases of corruption. It would be helpful to know what
> scenarios can cause corruption, if it can propagate between
> repositories and what restorations processes are available.
> 
> = shared hooks
> 
> In a small code shop, sharing hooks is practical. You want to be able
> to clone the main repository and have the same setup as your
> coworkers.
> 
> Having shared hooks in a distributed environment is more problematic
> because everybody needs to have the hooks available or you share the
> hooks with the repository and it adds mercurial interface
> dependencies. I guess these are the reasons why it isn't supported.

You could maintain your site-wide hooks in a repository of their own and
just have everyone keep a clone on their machines.

> = partial commits
> 
> In perforce you can reject some files when editing the commit message
> by removing their corresponding line. Mercurial doesn't push to have
> big commits so it's less vital but it could still be nice.

There are a couple of commit tools out there that provide this
functionality.  I prefer this one:

http://www.selenic.com/mercurial/wiki/index.cgi/QctExtension

> = hg debugconfig
> 
> I think that "hg config" would be a better name. It could also be
> extended to allow setting options too.
> 
> Another small enhancement would be to dump the origin of each setting
> with their value.

'showconfig' is a more descriptive alias for 'debugconfig'

There is also an extension which adds an 'hg config' command that does
allow setting options.

http://www.selenic.com/mercurial/wiki/index.cgi/ConfigExtension

> = dead bug tracker
> 
> Lots of tickets are living there. It doesn't inspire confidence in the
> software. However, the mailing list seem much more helpful since even
> FAQ-like questions are answered.

I expect an effort will be made to go through all the open bugs as
Mercurial approaches 1.0.

> = controlling branching
> 
> In a centralized setup, managing branches is a bit unfriendly. Either
> you use named branches, either you have to use ssh to spawn new
> clones. It would be helpful to have a more controlled environment like
> a web interface that protects against human errors.
> 
> = it's too fast !
> 
> This is almost a joke but when you're used to wait minutes for your
> operations, you're not even sure they happened in mercurial :)
> 
> From my poor experience, you end up using hg tip a lot because of
> that. Maybe it could be useful to have a result message and hg tip
> printed automatically on most operations.
> 
> = history and branches
> 
> I don't really see how you can track from which branch a changeset
> came from and who integrated the change in the logs. It would be nice
> to somehow be able to name cloned branches, so that each commit
> message would be prepended by that name.
> 
-- 
Steve Borho (steve at borho.org)
http://www.borho.org/~steve/steve.asc
Key fingerprint = 2D08 E7CF B624 624C DE1F  E2E4 B0C2 5292 F2C6 2C8C