On Wed, Feb 15, 2012 at 06:33:03PM -0300, Ignacio Riquelme Morelle wrote:
> On Wednesday 15 February 2012 18:04:51 Eric S. Raymond wrote:
> > Mark de Wever <[email protected]>:
> > > Personally I see not too much advantage by Git, git-svn works good
> > > enough for me. However IMO the uptime of GNA is getting lower over the
> > > years (it might be selective memory as well).
> > 
> > It probably isn't.  I've noticed it as well.
> 
> I haven't really had any persistent problems with gna.org's service for a 
> long 
> while myself, other than the recent, prolonged downtime we all know of, and 
> that can be mostly attributed to poor planning. Better staffed services with 
> fresh codebases occasionally have to deal with things like distributed denial 
> of service attacks or security breaches, so I'm not sure there's a real 
> difference for a project like Wesnoth where there isn't constant 24/7 
> activity.

True we don't need to have 24/7 support, I just have the feeling the
quality of GNA is getting lower and esr's post confirms that.

> I have repeatedly expressed concerns for moving to Git on IRC, so I'll try to 
> summarize them here for those who have not (been able) paying attention:
> 
> 1) With SVN, the bulk of the initial download on 'svn checkout' appears to be 
> the snapshot of HEAD that serves as the client's reference to resolve 
> differences against the BASE revision. The size of the uncompressed source 
> distribution tarball we offer through SF.net should be a good reference for 
> this size. (I'm deliberately ignoring metadata and the visible file 
> duplicates 
> in the checkout tree.)
> 
> Using Git, users (i.e. developers, prospective contributors, early adopters 
> and players taking advantage of tags) will have to download the entire 
> history 
> the first time in one go (git clone doesn't currently have a mechanism to 
> resume interrupted operations).

There is an option with cloning (--depth) to download only a part of
the history. It says that pushing upstream is problematic so not an
option for full developers, but good enough for a patch.

> Taking my git-svn tree as a reference, that would be something around 1.7 
> GiB. 
> I wouldn't have been able to download this much when I first joined, and I'm 
> not able to at the moment (nor for the foreseeable future) either.
> 
> This means that, assuming the service we choose doesn't offer something like 
> that, we'd need to host periodically-updated (possibly monthly) repository 
> clones that could be downloaded in a more convenient fashion using a tool 
> like 
> wget.

I think clone --depth=1 can do that as well.

> 3) The learning curve and organization. At the beginning (and even 
> afterwards, 
> as new people join the project) it will be very chaotic unless someone steps 
> forward and provides users with links to documentation (since IME even code 
> developers fail to RTFM at times), and most importantly, style guidelines 
> covering commit style/format, usage of branches, real merges vs. rebasing, 
> and 
> so on.

I agree with the learning curve issue as well. However it seems that for
Windows TortoiseGIT should make things simple. Regarding the commit
style/format; it's not that with SVN there is a good style guide and
I've seen enough commits in Wesnoth where the commit message was
useless. So I'd say don't blame the tool, but the user for that. 

I fear too much that the repo becomes a mess.

-- 
Regards,
Mark de Wever aka Mordante/SkeletonCrew

_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev

Reply via email to