GNA is down...

[Gregory Casamento]

Just FYI everyone,

GNA is apparently down at the moment. They're hoping to be back up by
2/10/12.

Regards, GC

[Gregory Casamento]

All,

GNA is still down. I'm wondering if we shouldn't explore
alternatives at this point.

In either case once it does come back I'm going to set up another svn
repo locally that pulls the latest every day so that we always have an
up to date copy of the repo.

GC

On Thu, Feb 9, 2012 at 1:24 AM, Gregory Casamento

Post by Gregory Casamento
Just FYI everyone,
GNA is apparently down at the moment.  They're hoping to be back up by
2/10/12.
Regards, GC
--
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
[phone] (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com

[Gregory Casamento]

To clarify: I mean a server which others can check out from if necessary. :)

GC

On Sat, Feb 11, 2012 at 8:16 AM, Gregory Casamento

All,
GNA is still down.   I'm wondering if we shouldn't explore
alternatives at this point.
In either case once it does come back I'm going to set up another svn
repo locally that pulls the latest every day so that we always have an
up to date copy of the repo.
GC
On Thu, Feb 9, 2012 at 1:24 AM, Gregory Casamento

Post by Gregory Casamento
Just FYI everyone,
GNA is apparently down at the moment.  They're hoping to be back up by
2/10/12.
Regards, GC
--
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
[phone] (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com

--
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
[phone] (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com

[Riccardo Mottola]

Hi,

Post by Gregory Casamento
All,
GNA is still down. I'm wondering if we shouldn't explore
alternatives at this point.
In either case once it does come back I'm going to set up another svn
repo locally that pulls the latest every day so that we always have an
up to date copy of the repo.

a read-only back-up server? thinkable. It would also offer an extra
back-up in case the hosting guys screw something up (remember the havoc
they did with savannah? )

I wonder if savannah could be set up for it.

Riccardo

[Fred Kiefer]

Post by Riccardo Mottola

GNA is still down. I'm wondering if we shouldn't explore
alternatives at this point.
In either case once it does come back I'm going to set up another svn
repo locally that pulls the latest every day so that we always have an
up to date copy of the repo.

a read-only back-up server? thinkable. It would also offer an extra
back-up in case the hosting guys screw something up (remember the havoc
they did with savannah? )
I wonder if savannah could be set up for it.

GNA is still not working. I don't see the point of providing a read only
SVN repository somewhere else. At least at the moment we have almost up
to date packages, which users should prefer anyway. The problem as I see
it is more for developers not being able to commit back their changes.
And here only a distributed version control system can help.
Up to now I have resisted this step, as it costs extra effort for all
developers to move to the new system. But not this step seems worthwhile
as it avoids the single point of failure that we have now. We still
could have the main git repository on GNA (If they offer it, this is
hard to check at the moment) and maybe a backup at Savannah. The big
benefit would be that even without these two servers we could keep on
working and could set up a new temporary repository for the exchange of
our changes.

The Etoile people should have a lot of experience with git already.
maybe they even have some clever scripts to transfer the current SVN
repository into a git one. And most of all we would need a good tutorial
to get old fashioned developers like me up to speed with git.

Of course this change will have to wait until GNA is up and working
again. But at least we should make up our mind now while we cannot
commit and most work on GNUstep is stalled.

Fred

[Ivan Vučica]

Please do consider Mercurial. Its CLI is slightly more friendly for new and for SVN users.

Regards,

Ivan Vučica
via phone

Post by Riccardo Mottola

GNA is still down. I'm wondering if we shouldn't explore
alternatives at this point.
In either case once it does come back I'm going to set up another svn
repo locally that pulls the latest every day so that we always have an
up to date copy of the repo.

a read-only back-up server? thinkable. It would also offer an extra
back-up in case the hosting guys screw something up (remember the havoc
they did with savannah? )
I wonder if savannah could be set up for it.

GNA is still not working. I don't see the point of providing a read only SVN repository somewhere else. At least at the moment we have almost up to date packages, which users should prefer anyway. The problem as I see it is more for developers not being able to commit back their changes. And here only a distributed version control system can help.
Up to now I have resisted this step, as it costs extra effort for all developers to move to the new system. But not this step seems worthwhile as it avoids the single point of failure that we have now. We still could have the main git repository on GNA (If they offer it, this is hard to check at the moment) and maybe a backup at Savannah. The big benefit would be that even without these two servers we could keep on working and could set up a new temporary repository for the exchange of our changes.
The Etoile people should have a lot of experience with git already. maybe they even have some clever scripts to transfer the current SVN repository into a git one. And most of all we would need a good tutorial to get old fashioned developers like me up to speed with git.
Of course this change will have to wait until GNA is up and working again. But at least we should make up our mind now while we cannot commit and most work on GNUstep is stalled.
Fred
_______________________________________________
Discuss-gnustep mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

[David Chisnall]

The Etoile people should have a lot of experience with git already. maybe they even have some clever scripts to transfer the current SVN repository into a git one. And most of all we would need a good tutorial to get old fashioned developers like me up to speed with git.

My experience of git is that it combines a bad architecture with a terrible implementation and a user interface that I can only assume was Linus' response to a bet that he couldn't create anything more painful to work with than Linux.

If we're considering a switch to a DVCS, then I'd strongly recommend taking a look at Fossil (http://www.fossil-scm.org). It has a lot of very nice features, including:

- Integrated bug tracker and wiki (no more problems where they're hosted in separate systems, bugs status updates can be easily tied to specific commits)

- A mode that automatically pushes changes upstream, so people only use it as a DVCS when they actually want DVCS features.

- A single (small!) binary for the server that can run in a chroot or jail, so it's really trivial for people to set up mirrors (I could happily run a backup instance on my server)

- A command line interface that seems like an actual human was at least consulted in the design (hg comes closer than git in this regard)

The only disadvantage I've seen of Fossil compared to git or hg is that it doesn't (yet) scale as well. For a comparatively small project like GNUstep, this is not a significant issue (NetBSD is in the process of switching to Fossil, and they have a lot more developers than us...)

David

-- Sent from my STANTEC-ZEBRA

[Ivan Vučica]

Post by David Chisnall
The only disadvantage I've seen of Fossil compared to git or hg is that it
doesn't (yet) scale as well. For a comparatively small project like
GNUstep, this is not a significant issue (NetBSD is in the process of
switching to Fossil, and they have a lot more developers than us...)

Another disadvantage is people's lack of familiarity with it, and (I
presume) smaller number of conversion tools between SCMs than git and hg
have.

Just quickly looking at Fossil's homepage, it says that it stores all
content in an SQLite database. If it's storing all files and/or diffs in
SQLite, does that end up being fast?

It does sound simultaneously interesting and scary with its integration of
additional tools, counter to the idea of a tool doing one thing and doing
it well. Hence, I wouldn't discount hg.

Only downside I can think of with hg is it being written in Python,
although I haven't seen it being significantly slow. And the boon of having
many people understanding what it does behind the scenes should not be
discounted.

I'm marking Fossil for further study.

[Quentin Mathé]

Post by David Chisnall
The only disadvantage I've seen of Fossil compared to git or hg is that it doesn't (yet) scale as well. For a comparatively small project like GNUstep, this is not a significant issue (NetBSD is in the process of switching to Fossil, and they have a lot more developers than us...)
Another disadvantage is people's lack of familiarity with it, and (I presume) smaller number of conversion tools between SCMs than git and hg have.
Just quickly looking at Fossil's homepage, it says that it stores all content in an SQLite database. If it's storing all files and/or diffs in SQLite, does that end up being fast?
It does sound simultaneously interesting and scary with its integration of additional tools, counter to the idea of a tool doing one thing and doing it well. Hence, I wouldn't discount hg.
Only downside I can think of with hg is it being written in Python, although I haven't seen it being significantly slow. And the boon of having many people understanding what it does behind the scenes should not be discounted.
I'm marking Fossil for further study.

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: Loading Image...

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.

Cheers,
Quentin.

[David Chisnall]

Post 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 think that's pretty much my experience. So, my first choice would be Fossil, my second choice hg. I'd rank git slightly above CVS.

I think the integrated wiki and bug tracker in Fossil could be very helpful to GNUstep, but if we're going to move from svn and not move to Fossil then hg is tolerable, while git is an abomination designed to destroy developer sanity.

David

-- Sent from my Difference Engine

[Nicolas Roard]

Post 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 :)

[Dr. H. Nikolaus Schaller]

Post by Nicolas Roard

Post 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 :)

I also have some experience with git doing Linux kernel development.
And a multi-year's experience with SVN.

I love some of the features which I would like to have in SVN:
* offline commit
* only one .git subdirectory at the root, i.e. painless addition and
moving around of subdirectories

But I also hate some of the commands sine they are not at all intuitive.
Even if I earmark them in a git compendium. And, if something goes
wrong you are usually completely lost and think about setting up
a new repository from your local copy :)

For the other proposals (hg and fossil) I have exactly the same opinion.

So for me it is fine with SVN, I can live with it, but git is also ok.

Nikolaus

[David Chisnall]

Post by Dr. H. Nikolaus Schaller
* only one .git subdirectory at the root, i.e. painless addition and
moving around of subdirectories

FYI: svn has this too in 1.7.

David

-- Sent from my STANTEC-ZEBRA

[Amr Aboelela]

I also suggest to use git, and if possible github.com which is widely known
by most developers now, and it can attract more volunteers to work with us.
It is easy to manage, add people, fork repositories, has issues (bugs)
tacking tool, has wiki for ur project, all for free, as long as the project
is public (open) which is true in our case.

[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.

Post by Gregory Casamento
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

Post by Gregory Casamento

Post 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

[Fred Kiefer]

Post by Eric Wasylishen
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 try to do a code review of all changes to gui and back. I do this by
clicking on the links send to the GNUstep-cvs mailing list. (For example
http://svn.gna.org/viewcvs/gnustep?rev=34741&view=rev)
Surely not the fastest way to do a code review, but I can do it even
when travelling from an internet cafe or my iPad.
What ever new DVCS we come up with it should be able to send similar
mails. Or it will increase the work load.

[Sebastian Reitenbach]

Post by Eric Wasylishen
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 try to do a code review of all changes to gui and back. I do this by clicking on the links send to the GNUstep-cvs mailing list. (For example http://svn.gna.org/viewcvs/gnustep?rev=34741&view=rev)
Surely not the fastest way to do a code review, but I can do it even when travelling from an internet cafe or my iPad.
What ever new DVCS we come up with it should be able to send similar mails. Or it will increase the work load.

Yes, those mails are important and I can just support this request, whatever will be used in the future, it should provide a similar feature.


But a bit more on the topic of code review, independently of what VCS will be used, let me share my experiences with OpenBSD:

Code review is usually done before its commited to the main tree. For each part of the tree, there is at least one, sometimes more maintainers.
If you have changes, you figure out, who is the maintainer, and send the patch for review. Important here is to send a patch inline, not as attachment.
Sending inline has the advantage you can just feed the mail to the patch command if a reviewer wants to test it actually. On many mail clients its a hassle to
view/open an attachment. Those reviewers then look at it, or even test, then give an OK, or request for changes.
Larger diffs with major changes are even sent to tech@, or a private m/l for a larger review by a wider audience, and requesting for testing it. Maintainers of the parts of the tree have rights to commit changes without review, but still, for major changes, its also for them recommended to
send the diffs to the m/l and request testing. When the commit is done, its noted in the commit message, who gave the OK.
Then, if things still break afterwards, the committer and reviewer(s) that gave the OK are responsible to fix it ;)

All this may seem to be much work, and may slow down development, but its indeed fairly effective, because most bugs/problems get catched, before
they enter the source tree, so people don't need that often spend lots of time trying to figuring out which of the commits broke a given feature.

Also, another thing that I like is that OpenBSD has scheduled release cycles, where customers/users can count on.
Before a release, developers are required to test, users are requested to test, and report back any issues they have.
This way, for a release, the base system and packages are all in sync, and supposed to work well.


Maybe gnustep should also have a scheduled release cycle, once or twice a year for a major new release, where all libraries, and main applications PC, Gorm, GWorkspace, ... are tested to work with each other, and released at the same time, even if there were only some minor changes or none at all.
This way, it would not happen that the latest base release doesn't play well with latest -gui/back for example ;)

All this said, OpenBSD has a comparably small developer team working on an operating system, compared for example to Linux. But without some rigid rules, to which people, especially the developers, have to adhere to, it wouldn't be possible to have a stable working release every half a year. There is only usually a handful of patches for each stable release.
Here is also a nice presentation detailing the OpenBSD release cycle: http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/

I don't want to push GNUstep into this direction, however, if it would be considered a good idea, and would go that way, I'd probably like it ;)
just wanted to share my experiences with the hope it may be of interest to someone.

cheers,
Sebastian

_______________________________________________
Discuss-gnustep mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

[David Chisnall]

Post by Sebastian Reitenbach
Code review is usually done before its commited to the main tree. For each part of the tree, there is at least one, sometimes more maintainers.
If you have changes, you figure out, who is the maintainer, and send the patch for review.

There are better tools for this. For a while for Étoilé Nicolas ran ReviewBoard[1], which let you upload a diff and let other people inspect it against the current svn head. LLVM has a mechanism that works the other way and scrapes the llvm-commits mailing list for patches as attachments and presents them in a web interface (I'm not sure what this uses, but I could find out).

For post-commit reviews, pretty much anything supports showing the diff in a convenient way. I usually look at GNUstep changes using viewvc on GNA, which lets you inspect a revision, see what has changed, and inspect diffs for everything. Fossil has a similar functionality built in (and, because the web UI can run locally, you can see the same interface whether connected or disconnected). Github has a version that reflects the git philosophy: more features, worse UI.

Post by Sebastian Reitenbach
Important here is to send a patch inline, not as attachment.

The down side of this is that mail clients and mailing list software have a habit of mangling diffs sent inline, so you often can't apply a diff sent this way. You can do code review, but not testing.

David

[1] http://www.reviewboard.org/

-- Sent from my Difference Engine

[Sebastian Reitenbach]

Post by David Chisnall

Post by Sebastian Reitenbach
Code review is usually done before its commited to the main tree. For each part of the tree, there is at least one, sometimes more maintainers.
If you have changes, you figure out, who is the maintainer, and send the patch for review.

There are better tools for this. For a while for Étoilé Nicolas ran ReviewBoard[1], which let you upload a diff and let other people inspect it against the current svn head. LLVM has a mechanism that works the other way and scrapes the llvm-commits mailing list for patches as attachments and presents them in a web interface (I'm not sure what this uses, but I could find out).
For post-commit reviews, pretty much anything supports showing the diff in a convenient way. I usually look at GNUstep changes using viewvc on GNA, which lets you inspect a revision, see what has changed, and inspect diffs for everything. Fossil has a similar functionality built in (and, because the web UI can run locally, you can see the same interface whether connected or disconnected). Github has a version that reflects the git philosophy: more features, worse UI.

Yeah, there are probably better ways of reviewing code changes prior commit. This is just to illustrate, how we do it there.
The main point I intended was just with the code review before commit. How its done, doesn't really matter. If the VCS has something built-in, or there are good tools available that help in that process, even better. I wasn' t aware of the ReviewBoard.
But it sounds, you dropped using it, why, the process is still too cumbersome?

Post by David Chisnall

Post by Sebastian Reitenbach
Important here is to send a patch inline, not as attachment.

The down side of this is that mail clients and mailing list software have a habit of mangling diffs sent inline, so you often can't apply a diff sent this way. You can do code review, but not testing.

Yep, I also had to learn that the hard way. I stopped using thunderbird in favor of using SOGo web interface, since I did not got Thunderbird to not to mangle inline diffs :(
But since then, I never had problems anymore with applying diffs from others, nor that others had problems with my diffs.

Sebastian

Post by David Chisnall
David
[1] http://www.reviewboard.org/
-- Sent from my Difference Engine

[David Chisnall]

I'm not sure what gave you this impression about the code review support in GitHub. The Pull Requests section for code review looks easy to use but more limited than ReviewBoard though.
ReviewBoard was more powerful (e.g. precise comparisons between patch revisions, review per patch revision, side-by-side diff, threaded comments) but had some UI pitfalls too.

For clarification:

I was comparing GitHub to the ViewVC and Fossil ability to show diffs, not to ReviewBoard (which, I believe, supports multiple VCS).

David

[Quentin Mathé]

Post by David Chisnall

Post by Sebastian Reitenbach
Code review is usually done before its commited to the main tree. For each part of the tree, there is at least one, sometimes more maintainers.
If you have changes, you figure out, who is the maintainer, and send the patch for review.

There are better tools for this. For a while for Étoilé Nicolas ran ReviewBoard[1], which let you upload a diff and let other people inspect it against the current svn head. LLVM has a mechanism that works the other way and scrapes the llvm-commits mailing list for patches as attachments and presents them in a web interface (I'm not sure what this uses, but I could find out).
For post-commit reviews, pretty much anything supports showing the diff in a convenient way. I usually look at GNUstep changes using viewvc on GNA, which lets you inspect a revision, see what has changed, and inspect diffs for everything. Fossil has a similar functionality built in (and, because the web UI can run locally, you can see the same interface whether connected or disconnected). Github has a version that reflects the git philosophy: more features, worse UI.

I'm not sure what gave you this impression about the code review support in GitHub. The Pull Requests section for code review looks easy to use but more limited than ReviewBoard though.
ReviewBoard was more powerful (e.g. precise comparisons between patch revisions, review per patch revision, side-by-side diff, threaded comments) but had some UI pitfalls too.

On a more general note, it looks to me that there are two difference kind of reviews. Reviewing patches (for major changes or from people without commit access) and reviewing commits. Now it is true that if you use a DVCS the line between the two is blurred, but it still exists imo.
For the first case, a dedicated tool like ReviewBoard is the best choice. For a DVCS and from a pragmatic viewpoint, an integrated solution based on Pull requests such as the one available on GitHub or BitBucket is the less work to set up and use.
For the second case the 'commit comments' feature of Github seems appealing. However replying to the commit mails as we do now, altough it is a bit less convenient, works well enough in my experience.

Cheers,
Quentin.

[Pirmin Braun]

Am Mon, 13 Feb 2012 14:09:41 -0700

Post by Eric Wasylishen
because it's slow with subversion

I'm very happy with tortoise-svn
--
mit freundlichen Gruessen/best regards

Pirmin Braun
seat-1 Software GmbH - Sinziger Str. 29a - 53424 Remagen
[phone] [phone] - skype:pirminb
Fax [phone]
http://www.seat-1.com ***@seat-1.com
http://intars.sourceforge.net

Geschäftsführer: Pirmin Braun, Ralf Engelhardt
Registergericht: Amtsgericht Coburg HRB3136

[Gregory Casamento]

All,

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
alphabetically):

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 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.

Post by Gregory Casamento
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.
- 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 Casamento

Post 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]

Haha... not quite alphabetically, this is what happens when you add
things to a posting last minute!

1) fossil
2) git
3) hg

;)

GC

On Tue, Feb 14, 2012 at 1:07 AM, Gregory Casamento

Post by Gregory Casamento
All,
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 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.

Post by Gregory Casamento
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.
- 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 Casamento

Post 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
[phone] (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com

[Matt Rice]

On Mon, Feb 13, 2012 at 10:09 PM, Gregory Casamento

Post by Gregory Casamento
1) fossil
2) git
3) hg

Of the 3 I'd highly prefer git, of the 3 i've only used git and hg,
and fossil might be great but I prefer not to learn another version
control system, and prefer to use the same version control system for
everything,
so I don't have to consider which project i'm working on at the shell.

thus were you to pick fossil or hg, i'd find a way to import into git,
and that is usually a bit of recurring pain,
that said my contributions to gnustep are minimal to non-existent at
this point so feel free to discount my preference. while I consider
git optimal, stick those in a hat, pick one and it'll be better than
SVN.

[Richard Frith-Macdonald]

Post by Gregory Casamento
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.

I'm afraid I agree with this point (and I think Nicolas Roard had a similar point to make about going with less popular software).
Just from looking at their documentation etc, fossil does seem the most appealing, and more fun ... but GNUstep already seems somewhat marginalised ...

So ... can I put in a wish list ...

1. A properly distributed system ... one where we have a loose cluster of main servers which automatically keep in sync, rather than having a single central hub (single point of failure).

2. I'd like to see a system which would generate ChangeLog files for us so we don't have to write them by hand as well as adding commit comments.

3. I'd like RCS and email feeds of changes from the central systems, so we are notified of commits and can review them easily (e.g. click on a link to see the commit log and diffs)

4. I'd like a good web-gui usable both on central systems and on the local database

The combination of (1) and (3) is quite tricky ... I don't know how well any of the systems actually support it.

[Fred Kiefer]

Post by Richard Frith-Macdonald

Post by Gregory Casamento
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.

I'm afraid I agree with this point (and I think Nicolas Roard had a similar point to make about going with less popular software).
Just from looking at their documentation etc, fossil does seem the most appealing, and more fun ... but GNUstep already seems somewhat marginalised ...
So ... can I put in a wish list ...
1. A properly distributed system ... one where we have a loose cluster of main servers which automatically keep in sync, rather than having a single central hub (single point of failure).
2. I'd like to see a system which would generate ChangeLog files for us so we don't have to write them by hand as well as adding commit comments.
3. I'd like RCS and email feeds of changes from the central systems, so we are notified of commits and can review them easily (e.g. click on a link to see the commit log and diffs)
4. I'd like a good web-gui usable both on central systems and on the local database
The combination of (1) and (3) is quite tricky ... I don't know how well any of the systems actually support it.

I just stumbled over this link. Maybe it helps making the choice where
to host:

http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities

[Quentin Mathé]

Post by Fred Kiefer
http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities

For Mercurial, BitBucket is a good alternative to GitHub. It supports Git too. BitBucket used to be lagging behind GitHub but now they are more or less equivalent.

BitBucket has some small downsides, it doesn't support Inline Editing and Inline code comments unlike GitHub (this last point is troublesome for code reviews).
However it offers side-by-side diff which is much better for browsing commits and code review (Pull Requests).

For Git, there is Gitorious too, which is dedicated to open source projects and seem to offer side-by-side diff too.

Cheers,
Quentin.

[Derek Fawcus]

Post by Richard Frith-Macdonald
So ... can I put in a wish list ...
1. A properly distributed system ... one where we have a loose cluster of main servers which automatically keep in sync, rather than having a single central hub (single point of failure).
2. I'd like to see a system which would generate ChangeLog files for us so we don't have to write them by hand as well as adding commit comments.
3. I'd like RCS and email feeds of changes from the central systems, so we are notified of commits and can review them easily (e.g. click on a link to see the commit log and diffs)
4. I'd like a good web-gui usable both on central systems and on the local database
The combination of (1) and (3) is quite tricky ... I don't know how well any of the systems actually support it.

I'd actually say that (3) sort of enables (1).

Most VCS that I know of have the ability to add pre/post action hook scripts.

So one has to set up a hook for updates to the 'central' respository such that it sends out
notifications. One could then have that notification received by one of the central servers
cause it to pull updates from the designated 'central' server.

Or are you after something even more automatic? Some sort of netnews-like flood filling?

I'd suggest that this is sort of the best that should be necessary, as in a proper
DVCS, every user has a complete copy of the history. So if the central system goes
down, one can easily designate a new central system and co-ordinate via it.

Look at what happened with Linux when kernel.org was hacked and went down.

As for (2), I'd suggest that a script could be made that generates the correctly
formatted ChangeLog, and that it could be run upon demand (i.e. the ChangeLog
not be version controlled as such). Then when commands are given to generate a
distribution tar-file, the script is triggered to create a new ChangeLog which
is then packaged up. That way the VCS contains the defintive history, and
the ChangeLogs are simply a deriviative.

.pdf

[Derek Fawcus]

Post by Derek Fawcus

Post by Richard Frith-Macdonald
3. I'd like RCS and email feeds of changes from the central systems, so we are notified of commits and can review them easily (e.g. click on a link to see the commit log and diffs)

I'd actually say that (3) sort of enables (1).
Most VCS that I know of have the ability to add pre/post action hook scripts.

For git, there is an example hook for sending out emails; there are plenty
of sites describing such hooks, and as an example of what can be done, look
at http://toroid.org/ams/git-website-howto.

.pdf

[Aria Stewart]

Post 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.

Also, if the last time you used git was 1.4.x, things have gotten much, much
better. It still has a command line surface area the size of Eurasia, but
common tasks are among a short list of simple ones.

It's easy to "corrupt" your history, but also easy to recover it (There's a log
of all changes to what names refer to what, and you can usually find the commit
you lost there -- and if you can find that, you have the entire history from
that point.)

git's getting good. IT's just getting good by accretion.

[Gregory Casamento]

Fred,

I believe this is the right move. A move to git would solve many
problems. I'm honestly concerned about staying with GNA in general.
This one week of downtime has really made me consider how safe our
code is on GNA.

I would say that, if savannah currently supports git, we may want to
make a move back to savannah in that case since it would consolidate
all of our stuff in one place.

If anyone has any objections to use GIT I would like to hear it now.

GC

Post by Riccardo Mottola

GNA is still down. I'm wondering if we shouldn't explore
alternatives at this point.
In either case once it does come back I'm going to set up another svn
repo locally that pulls the latest every day so that we always have an
up to date copy of the repo.

a read-only back-up server? thinkable. It would also offer an extra
back-up in case the hosting guys screw something up (remember the havoc
they did with savannah? )
I wonder if savannah could be set up for it.

GNA is still not working. I don't see the point of providing a read only SVN
repository somewhere else. At least at the moment we have almost up to date
packages, which users should prefer anyway. The problem as I see it is more
for developers not being able to commit back their changes. And here only a
distributed version control system can help.
Up to now I have resisted this step, as it costs extra effort for all
developers to move to the new system. But not this step seems worthwhile as
it avoids the single point of failure that we have now. We still could have
the main git repository on GNA (If they offer it, this is hard to check at
the moment) and maybe a backup at Savannah. The big benefit would be that
even without these two servers we could keep on working and could set up a
new temporary repository for the exchange of our changes.
The Etoile people should have a lot of experience with git already. maybe
they even have some clever scripts to transfer the current SVN repository
into a git one. And most of all we would need a good tutorial to get old
fashioned developers like me up to speed with git.
Of course this change will have to wait until GNA is up and working again.
But at least we should make up our mind now while we cannot commit and most
work on GNUstep is stalled.
Fred
_______________________________________________
Discuss-gnustep mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Ivan Vučica]

Greg,

On Mon, Feb 13, 2012 at 18:03, Gregory Casamento

Post by Gregory Casamento
If anyone has any objections to use GIT I would like to hear it now.

you mean apart from what David, Quentin and I have said? :-)

[Gregory Casamento]

Indeed... they are good arguments against it. I think we can consider
git off of the table.

GC

Post by Ivan Vučica
Greg,

Post by Gregory Casamento
If anyone has any objections to use GIT I would like to hear it now.

you mean apart from what David, Quentin and I have said? :-)
--

[Riccardo Mottola]

Hi,

Post by Ivan Vučica
Greg,
On Mon, Feb 13, 2012 at 18:03, Gregory Casamento
If anyone has any objections to use GIT I would like to hear it now.
you mean apart from what David, Quentin and I have said? :-)

count me in too.

For your fun, use google or bing and search "GIT" + "pile of poop" or
similar expressions :) Very informative. Ha ha ha.

I stand to my proposal to move back SVN to savannah and try to use gna
as a sort of read-only mirror.
At least on savannah we can mail Stallman directly if the lights go ou.

Riccardo

[Richard Frith-Macdonald]

Post by Gregory Casamento
If anyone has any objections to use GIT I would like to hear it now.

I have one ... nobody seems to have anything good to say about it!

I think its main selling point is that it was one of the first distributed systems ... But first is not best.

I think savannah supports both mercurial and bazaar (and possibly others) as well as git ... And from what I've read of them they both (particularly mercurial) seem much better (simpler, faster, esier to use).

Is ther a positive reason to pick git?

[Gregory Casamento]

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

GC

On Mon, Feb 13, 2012 at 12:31 PM, Richard Frith-Macdonald

Post by Richard Frith-Macdonald

Post by Gregory Casamento
If anyone has any objections to use GIT I would like to hear it now.

I have one ... nobody seems to have anything good to say about it!
I think its main selling point is that it was one of the first distributed systems ... But first is not best.
I think savannah supports both mercurial and bazaar (and possibly others) as well as git ... And from what I've read of them they both (particularly mercurial) seem much better (simpler, faster, esier to use).
Is ther a positive reason to pick git?

[Derek Fawcus]

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

Oh well...

Actually, I quite like git; largely because of it being a collection of lots
of little tools, such that one can (if one desires) easily extend it.
That is without having to learn another scripting language and plugin architecture (hg).

This being down to the decomposible nature of the parts. Yes the 'plumbing'
part can be a sharp tool, but if one works at the 'porcelain' level, I've
not found it any more dangerous than other tools.

I've certainly managed to destroy history / data with all VCS systems I've ever
used - that is why one has backups.

I'd say a lot is down to perception, and git has gained a reputation which
is not wholy deserved - largely down to how the 'porcelain' grew after the
'plumbing', and having to maintain some backward compatibility with older
CLI options and behaviours.

As to git vs hg, I'd say at a high level they're largely similar, but I'm
more familiar with git.

The bit I like about using git is the way it allows one to hack up some code
committing as one goes, and then in effect to rework the history of the
commits before pushing out to a public repository. I say 'in effect' as
the original history is not lost unless one chooses to lose it. Maybe
hg offers the same ability?

.pdf

[Nicolas Roard]

On Mon, Feb 13, 2012 at 9:03 AM, Gregory Casamento

Fred,
I believe this is the right move.   A move to git would solve many
problems.   I'm honestly concerned about staying with GNA in general.
 This one week of downtime has really made me consider how safe our
code is on GNA.

I agree -- we should decide on something distributed and use it. I
have a CL that has now balooned to 1600 lines that I cannot submit
since a week -- highly frustrating. It really highlight the fact that
we relay way too much on GNA.