Promoting the use of Mercurial; was: Re: gnome dvcs survey results

[Bill Barry]

Theodore Tso wrote:
> On Wed, Jan 07, 2009 at 07:50:36AM -0700, Bill Barry wrote:
>   
>>> This somehow bothers me, since it shows that some people use
>>> momentum as main argument for switching to git.
>>>       
>> I think that momentum _is_ the main argument for switching to git from a 
>> centralized VCS. You will find a git bias in the userbase for git (just 
>> like you would find an hg bias in hg users and a bzr bias in bzr users).
>>     
>
> People *will* use momentum as an argument, because it makes sense.
> The arguments there is two fold; if a large percentage of the
> developers already know a particular SCM tool, then there is less
> training that will be necessary.  The second argument is that if there
> are more people using it, there is likely to be more development for
> support tools that surround a particular SCM, and to a lesser extent,
> it might make a difference to the speed at which a particular SCM
> develops.  Hg can make a counterargument with the latter, based on the
> fact that python is a easier language to write extensions than C.
> (OTOH, I personally find it easier to write extensions using shell and
> the low-level git functions but that's because I never got around to
> learning python, but am much more of a shell/sed/awk/perl kind of guy.
> Everybody's mileage will vary here...)
>
> Note, BTW, that the other momentum argument is simply number of
> developers and relative activity on the mailing list.  The git mailing
> list averages about 2900 messages/month; mercurial seems to be
> averaging about 470 messages/month.  If there are more people working
> on making a project better, all other things being equal, it's a good
> thing --- although obviously a few star programmers can make a huge
> difference either way.
>
>   
>> The main advantage of git is that there are a lot of people who are 
>> familiar with it as you get closer to projects that potentially share 
>> developers with the kernel. Outside of this group, git support tends to 
>> fall away because of many disadvantages:
>> * non-uniformity in command arguments
>> * too many core commands
>> * relative lack of windows support
>>
>> (though someday git will probably solve both the first and last problem)
>>     
>
> Arguably most of these problems have been solved already.  Git 1.6 has
> already moved out many of the lower-level commands, and if you compare
> the outputs of "git help" with "hg help", they are roughly the same.
> And the native windows port of git is rapidly approaching usability.
>
>   
>> I think overall that git suffers from a lack of direction.
>>     
>
> I suspect you're saying this because you haven't been following git
> development.  I track both, and they do have a development agenda that
> includes making the UI easier to use, hiding the low-level commands
> (already done in git 1.6), and there are developers that are working
> quite steadily on the Windows ports.
>   
This is probably true. I gave up following git development about 6 
months ago because there was too much noise. I couldn't seem to see the 
big picture, just lots of tweaks here and there to whatever anybody felt 
like doing. At the time, cheetah dev was stopping and the project looked 
like it was going to be unmaintained, msysgit was buggy and it seemed 
like people didn't care to fix it (and I had no time to look at it 
myself), and the majority of stuff on the list was all just people 
complaining about their problems and trying to get help fixing them. In 
contrast, this mailing list was discussing 3 or 4 bugs at the time, 
movement was starting on the pbranch extension, 1.0 had recently shipped 
and it was pretty easy to figure out what was going on.
> I'd ask the flip question, which is what is Mercurial's long-term
> direction?  Or, put another way, what does Mercurial what to be when
> it grows up?  If it's just "faster than bzr, slower than git, but
> easier to use and hey, we have a good Windows port", that's not very
> satisfying.  So if Mercurial isn't feature-complete, what features are
> people planning on adding in the future?
>   
We do need to update the roadmap. It seems to have fallen apart somewhat 
(it used to be linked right from the index to here: 
http://www.selenic.com/mercurial/wiki/index.cgi/RoadMap). There are some 
things I would like to see on it:
* hg to svn pushing and pulling fully implemented (perhaps even both 
ways: use hgweb as an svn server or hg as a client to svn)
* a better workflow for shelving patches [1]
* bound branches (straight up stolen from bzr)
* graph implemented in hgweb (this might already be done, I just don't 
have the latest update)
* pushlog shipping with hgweb
* tortoisehg shipping on the same day as hg (possibly even dropping the 
tortoise brand, just pushed as "hg for windows")
* better documentation when it comes to extensions
* a better chapter at the beginning of the book to make it easier to get 
up and running with the 6 or so commands most users really need (push, 
pull, update, commit, merge, addremove)
* another chapter promoting some good workflows and practices
* a good program that will hook up to a mailing list and read patches 
off of it into a holding area for committers to manage right from their 
hg cli [2]

[1]:
The current choices are afaik:
1. mq: good, but you need to do a lot manually when working with many 
patches that are independent. For example:
... work some ...
hg qnew -f feature1.patch
... work more ...
hg qrefresh
... unfinished (and doesn't compile) but now you need to go work on 
something else ...
hg qpop
hg qnew somebigbugfix.patch
... work more ...
hg qrefresh
... unfinished (and doesn't compile) but now you need to go work on 
something else ...
hg qpop
hg qnew anotherfeature.patch
... work more ...
hg qrefresh
... told to get back to working on feature1 ...
Now you have to manually move stuff around in the series file so that 
you can get back to feature1, even though the other patches may be 
completely independent. When you start getting more than about 5 of 
these at a time it begins to become a bit of a hassle to deal with (one 
of my queues has over 50 items on it right now; since the main working 
copy is almost a gig in size it is a bit difficult to just work on these 
in separate clones). Also it is difficult to share a patch queue with 
another person (because the series file might be in a different order 
and may not contain the same patches), it is much easier to simply share 
the patch file and have the other person import it.

2. pbranch, requires hg 1.1 (for which tortoisehg isn't released yet), 
requires clones? (I think, the documentation isn't very clear there, 
does it work with named branches?)

3. shelve extension - ok, but why is it interactive? I'd think it should 
work just like this:
hg st
... shows a bunch of files with altered statuses
hg shelve patchname.patch
hg st
... shows nothing
hg unshelve patchname.patch
hg st
... shows changes from first hg st
hg shelve
(reshelves to patchname.patch)
hg unshelve
(unshelves patchname.patch)
hg shelve
... do work
hg shelve newpatch.patch
hg unshelve patchname.patch
(now newpatch is shelved away, as you are working on patchname.patch, if 
you unshelved newpatch now it would complain that you have local changes 
for patchname.patch; if you commit or revert all it would forget that 
you have a patch unshelved)
hg listshelves (alternative name could be "hg attic",
(lists all available shelves, one per line, essentially simply do a 
dirlist of .hg/shelves for all files that don't start with .)

mq could potentially work the same way if only there was a command that did:
1. refresh whatever is currently at the top of the queue
2. pop all patches
3. add all the files that are in the patches dir into the series file
4. move the named patch to the first line in the series
5. push this patch


--
Actually looking at the source for hgshelve I don't think it would be 
that difficult to write what I am thinking. What do I need to do to 
write an extension for tortoisehg?


[2]
It would for example read the patches right off of this list and put 
them somewhere. This would be combine with an extension set for hg:
hgrc:
[extensions]
extensions.pq =

[defaults]
default-pq = https://somewhere (or ssh:// or ...)

commands:
hg pqlist - lists patches located at somewhere
hg pqtake - pulls a patch down into the user's mq repo and marks it as 
taken on the list (ie somebody is looking at it)
hg pqclear - marks a patch as cleared on the list (ie. not yet taken by 
anyone)
hg pqreject [pqaccept, pqdelete] - deletes a patch from the list
hg pqcomment - opens a text editor with the patch quoted for a person to 
mark up with comments; to complete command this sends the comments as a 
reply to the patch on the mailing list

in addition to this there would be some sort of acl for who can list and 
comment vs who can take, clear and delete

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20090107/4e06d0a1/attachment.htm