Haha... not quite alphabetically, this is what happens when you add
Post by Gregory CasamentoAll,
What follows are my general thoughts on this whole discussion thusfar.
I'm only throwing out these thoughts for consideration at this point.
All of Eric's statements are excellent arguments for GIT. The value
of something like github, since it is widely used and allows for any
number of people to pull from our repository and create their own
variations on GNUstep, shouldn't be undervalued. It seems I spoke a
little too soon when I said git was off the table. Using github
would give us access to a large community of people who could
potentially help make GNUstep a better project and that's what we
ultimately all want. That being said git's user interface is terrible
and there is a learning curve associated with using it. GIT can be
difficult to deal with at first and can make it very easy to lose data
if you make a mistake.
The way I see it, we have three real choices at this point (listed
1) git
2) hg
3) fossil
git and hg are both supported by savannah at this point. Both are
decentralized. Both are well tested and well known and proven.
Currently, I know git better than I do mercurial, so I have no basis
on which to judge whether or not mercurial is better or worse. I only
have what everyone else has said comparing the two systems.
Fossil, while it seems good and very comparable to both git and hg is
not very well known and not widely adopted. I've learned in my
career that, while something might be technically better, that's,
sadly, not always enough. Still we may want to consider this option
as well, if it's promising enough it might be worth it.
Each of the pros and cons of these choices should be weighed
individually and carefully. GNUstep changing it's source code hosting
is something which has happened only once in a decade so we need to be
sure of our choice once it's made and we need to be sure that we can
live with whatever implications come out of that choice. This is not
something that will be done lightly or overnight.
Another concern we should address as part of this effort is that the
current structure of the repository is somewhat convoluted and
confusing. I would like to resolve this issue when we make this
move. We may wish to consider splitting out all of the sub projects
in GNUstep into separate projects so that they can be individually
managed.
Thanks, GC
Post by Eric WasylishenHi,
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.
Post by Gregory CasamentoI 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.
- 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.
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
Post by Gregory CasamentoPost by Quentin Mathé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
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
_______________________________________________
Discuss-gnustep mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
--
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com