Re: GNA is down...

[Eric Wasylishen]

Hi,
I would be strongly in favour of switching to a dvcs, and in particular git, 
with mercurial as a second choice. There's no excuse these days not to have the 
entire project history stored on your hard disk, whereas in 2005 or so, if you 
wanted a free dvcs you had a small selection of obscure tools.

One big advantage of dvcs's, which is something I don't hear discussed a lot, 
is how much better the GUI's are for reviewing recent commits made by other 
people. In my opinion, every active developer should be reviewing the diffs of 
most commits to their project. It's simply too slow for me to deal with in 
subversion (look up the revision number, run svn diff -rRevisionBeforeFoo:foo | 
vim -, wait several seconds, read the diff, look up the next rev # I want to 
read, repeat…). Is everyone else reviewing most diffs of recent commits? My bet 
is people aren't reviewing as much as they could because it's slow with 
subversion.

> I don't think there are any positive reasons to pick git, so it's off the 
> table.


When I decided to learn a dvcs to use for all of my personal projects, I picked 
git because I liked the hosting sites available for it the best (in particular, 
github), and in other respects it seemed at least as good as the other major 
contenders.

Some points from my experience with git (2 years, but I stick to the basic 
features):

- the git index feature is very handy when coupled with a good GUI (for 
example, the official git gui app, or the closed-source SourceTree mac app.) If 
you haven't used this feature, I highly recommend trying it. With a good tool, 
it amounts to interactive diff editing - you can interactively choose which 
parts of you working copy to "stage" for the next commit. The two tools I 
mentioned let you select a range of lines with your mouse and stage/unstage 
them in the right-click context menu - very powerful. e.g. often I have some 
logging code I don't want to commit. Unlike some other "power user" features in 
git (rebasing, etc.) this one is something you can learn on your own and pretty 
much impossible to screw anything up with :-).

- git appears to be the most popular dvcs. IMHO this importance of this point 
shouldn't be underestimated - it means there is a lot of help available; it's 
really easy to find tutorials, quick-reference cards, great hosting websites. 
New developers are more likely to know it than obscure dvcs's.

- the argument that git is harder to use than subversion, or that the git 
command line tools have a terrible UI doesn't match my experience. I find the 
comand-line menus in subversion awful (e.g. svn update. "Foo.m is conflicting, 
type 'e' to edit, 'p' to postpone, etc.) and have lost work by typing the wrong 
command more than once.  I've messed up git working copies only once or twice - 
same with subversion - by trying commands without understanding what was going 
on.


There are lots of git vs mercurial or git vs foo comparisons available on the 
web, some better than others. Here's one git vs mercurial example:

http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/

I would be hesitant to switch to a dvcs other than git or mercurial, because 
they're both proven (used by many major free software projects), both good and 
roughly equivalent, and potential new developers are likely to know these. 
Fossil sounds nice but is relatively obscure. I've heard bazaar highly 
recommended by friends, but again, not that many people use it outside of the 
Ubuntu devs.

Also, if switching to a dvcs for GNUstep means that I have to learn a new 
system (mercurial would be new for me), I want it to be something that I can 
expect to use in other open-source communities or jobs (which you can expect of 
mercurial and git, given they are pretty widespread.)

Regards,
Eric


On 2012-02-13, at 10:38 AM, Nicolas Roard wrote:

> On Mon, Feb 13, 2012 at 5:30 AM, David Chisnall <theraven@sucs.org> wrote:
>> On 13 Feb 2012, at 13:23, Quentin Mathé wrote:
>> 
>>> I quite like Fossil, but I'd be fine with Mercurial too. Both seems to have 
>>> a similar command-line interface:
>>> Fossil: http://www.fossil-scm.org/index.html/doc/trunk/www/quickstart.wiki
>>> Mercurial: 
>>> http://ivy.fr/mercurial/ref/v1.0/Mercurial-QuickStart-v1.0-120dpi.png
>>> 
>>> As a disclaimer, my experience is limited to Git. I used it for several 
>>> months, although it has some nice features, but its command-line interface 
>>> is a pain, and it's easy to corrupt your local repository history by 
>>> mistake.
> 
> I've been using git for the last couple of years at work (well, a mix
> of git and our own scripts, gerrit), and while the beginning was a bit
> annoying, I really can't work without it now. I agree that you indeed
> can shoot yourself in the foot with git, but if you follow a
> reasonable workflow it's pretty simple (i.e. git add -p, git commit).
> And its merge capabilities are pretty awesome. So if you are looking
> at it as a replacement for your SVN workflow, you can keep things very
> simple I think; more complicated things are complicated, but at least
> they are doable (not really the case with SVN).
> 
> Other than the merge capabilities, I think the other important point
> with git is that it's now widespread, so it's pretty easy to find
> documentation or people to teach you.
> 
> That being said, I never played with mercurial, and heard good things
> from it as well. Fossil looks interesting, I'm just a bit wary of
> picking another obscure technology :)
> 
> -- 
> Nicolas Roard
> "I love deadlines. I like the whooshing sound
> they make as they fly by." -- Douglas Adams
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep