Re: GNA is down...

[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
<greg.casamento@gmail.com> wrote:
> 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
>
> On Mon, Feb 13, 2012 at 4:09 PM, Eric Wasylishen <ewasylishen@gmail.com> 
> wrote:
>> 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
>>
>>
>> _______________________________________________
>> Discuss-gnustep mailing list
>> Discuss-gnustep@gnu.org
>> 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



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