Re: [Debconf-team] SVN -> GIT migration
Hi,
(a bit late, but...)
On Sat, Jul 07, 2012 at 01:49:10PM -0600, Gaudenz Steinlin wrote:
>
> [git conversion things]
I have talked to Moray about this, and we both basically agree (but
the words here are mine)... but it seems the main advantage to git is
that it is cool, not that it's better for this case.
First and foremost is the institutional memory. If you want to work
on DebConf N, you're going to want to know about DebConf N-1 and N-2
and N-3 and so on. As a specific example, I imagine DC13 people are
going to be interested in getting sponsors now. The DC12 and DC11 and
so on repos will be good for that - depending on how hard you scrape,
you may want all of them. So... that means continuing to give people
access to old repos, nullifying the "security" here? Or go and copy
over previous years to the current repo each time?
git is good for code. It has tons of nice features like branching and
local copies. But I have always thought that subversion is fairly
ideal for our use case.
One of the complains is size of the repos. Imagine what it's like
when you need full history of all changes of all of our binary files,
instead of just the current version. Subversion handles this nicely.
Also, with subversion you can do partial checkouts. It is one of the
first things I figured out when I had to use subversion for
debconf-data:
$ svn co --depth=immediates svn+ssh://svn.debian.org/svn/debconf-data/
$ cd debconf-data
$ cd dc12
$ svn co --depth=full dc12
$ # Hm, I want to check one file in dc11?
$ cd ../dc11
$ svn co --depth=immediates
Really, exactly how I hope DebConf repos would behave.
git does nice branching and local copies... but most of our data is
designed to reflect "the real world case" where there is only one
version of facts, and everyone should have that as much as possible.
I agree and empathize with the fact it is hard to get people access.
I would suggest cc'ing debconf-team on requests to add people as
commiters. It is also one of the reasons I try so hard to minimize
the amount of private date put into debconf-team, and maximize the
public part in debconf-data. (If you'd like to find new people for
the admin team, I think it would be very well appreciated!)
There are with respect to private data being in the repositories.
While I've said this in IRC, private data should only be put in if the
need for sharing makes long-term storage worth it. This is the case
for most things historically put into it. Perhaps, if people wanted a
split, a more logical one would be a repository for just the
registration team/travel sponsorship, since they are the ones with all
of the attendee information.
Note that none of this applies to code, such as pentabarf, etc.
I realize that I am doing a lot of talking here, and not much doing.
I feel pretty dirty telling others that their work isn't appreciated.
However, nonetheless, every year I see tons of people come into
DebConf with great idealism about technology, who eventually seeing
that putting on a DebConf is about managing complexity and finding a
nice balance. I wish that I could do more, but I am currently trying
to finish my degree so I have very limited time. In 2-3 months, I
will have much more time and can take a more active role in things,
perhaps by writing up various best practices (make a list for me!).
I'm sure there has been much discussion at debconf itself, and if you
all would like to go ahead, I'll wish you the best of luck and do what
I can with the new system.
- Richard
--
| Richard Darst - rkd@ - boltzmann: up 1097 days, 19:18
| http://rkd.zgib.net - pgp 0xBD356740
| "Ye shall know the truth and -- the truth shall make you free"
Reply to: