Re: Wesnoth project hosting

As far as I and other devs checked, unfortunately Github doesn't offer 
attachment functionality - which is vital for our bugs (think of replays 
for example).

On the other hand, Sourceforge.net might be a good contender.

Timo

On 15-Feb-12 23:17, Iurii Chernyi wrote:
> Hello,
>
> On Wed, Feb 15, 2012 at 10:04 PM, Eric S. Raymond<esr <at> thyrsus.com>  wrote:
>> I have written a tool that can scrape the GNA bugtracker.  The problem isn't
>> export but import - loading it into anywhere else.  It is probably not
>> yet feasible to move the tracker.
> In the bugtracker, we have bugs, comments, patches, attached files -
> the data model is rather small. If we pick the new bugtracker ahead of
> time, it should be possible to prepare for migration with minimal
> losses of data, writing the code for import and testing it. Even if
> we'll import via 'standard' input channels, we'll successfully salvage
> most of the content. If the new bugtracker will have some bulk import
> capabilities (or if it'd be possible to negotiate for such a
> capability or host our own bugtracker instance), even better.
>
> So, I think that we should start figuring out 'where to move'.
>

Re: Wesnoth project hosting

Ignacio Riquelme Morelle <shadowm2006 <at> gmail.com>:
> In the matter of CIA.vc hooks for Git, all those I have seen so far have 
> annoying limitations such as the inability to present real merges in a useful 
> fashion, commits being reported out of order, or no tag object reports. I 
> believe I have seen CIA reporting commits to hosted KDE projects addressing 
> some of these points, but I haven't found the hook's source yet.

Talk to me.  I maintain the CIA hooks that are in the git project
repo.  If you know of a more advanced version, I'm willing to merge
those features and changes.

> 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 know how to handle this.  I've managed several large svn-to-git
transitions.
--

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev <at> gna.org
https://mail.gna.org/listinfo/wesnoth-dev

Re: Wesnoth project hosting

On 15 February 2012 22:33, Ignacio Riquelme Morelle
<shadowm2006 <at> gmail.com> wrote:
> 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).
>
> 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.

Hi all,

Isn't most of the 1.7GB music, with code and images etc. taking up a
relatively small amount of space? Wouldn't it be possible to use the
opportunity of a repo switch to also separate music and other binary
blobs into a different repository to make the core repo smaller and
easier to work with?

Ilor

Re: Wesnoth project hosting

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 <koraq <at> xs4all.nl>:
> > > 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.)
> 

Re: Wesnoth project hosting

Hi guys,

Let me summarize points about project hosting (which I found on wiki & letters):
1) Project hosting should both code hosting & issue/bug tracking

Github allows this:
https://github.com/battle-for-wesnoth/svn/issues?milestone=1&state=open

2) Project hosting should track references between code & issues

https://github.com/blog/831-issues-2-0-the-next-generation

3) Git has a high learning curve (important for not-a-developers)

We can has a main subversion repository and upload data to git by
svn-post-commit hooks.
git svn dcommit allows to commit to svn directly
git allows manage separated branches, and commit their to svn when
branch is completed.

4) Github has size limitation

(NOTE: just for a non-free projects, as you can easy see
https://github.com/battle-for-wesnoth/svn - complete BfW repository on
github)

5) We are going to host addons on git/similar.

github allows this

Re: Wesnoth project hosting

Mark de Wever <koraq <at> xs4all.nl>:
> > On the other hand, one of the things that experience tells me is that
> > a Wesnoth migration would be a huge, messy project.  The sheer size
> > of the repo would produce a scale problem in itself - a full download of
> > all branches runs my development machine out of disk space!
> 
> I assume that is before you do a git repacking operation. Our git-svn
> repo is less than 2 GB and AFAIK only misses the website branch.

I was talking about a svn download. 

> > This doesn't mean it can't be done.  It does mean it can't be done
> > *quickly*.  But we probably want to wait until I ship reposurgeon 2.0
> > anyway; I'm still chasing some bugs in the svn support.
> 
> Haven't looked at reposurgeon yet, but if that tool can make it easier
> the better 

reposurgeon is a repository surgery tool; one of its main uses is for
high-quality repository conversions.  See http://catb.org/~esr/reposurgeon/

The 2.x version will have direct support for reading (though not
writing) Subversion repos.  Already, even with its known bugs, it's
the best svn-to-git converter in existence - because it's the only one
that can handle mixed-branch commits.

> > However, I think we should probably begin preparing for a move.  Gna
> > is understaffed and undermaintained, and the Gna codebase is creaking
> > and old. I would feel much more secure if the repo were migrated to
> > somewhere like github or gitorious.