One possibility would be to create a GSoC branch from
trunk and give them SVN access to just that branch...
On May 26, 2006, at 2:46 PM, Bill Dudney wrote:
Hi All,
I prefer the patches approach. I know its a pain in the neck for
the student but IMO its more likely to result in stuff we can
maintain going forward (assuming the student is not able to
continue after the SoC is over) because it has to be reviewed
before being applied.
Even on new app development it makes sense assuming that we get a
patch once a week or once a day or whatever, as long as its small.
If we can make SVK work (I'm interested too) then I'm OK with that
as well as long as the patches are small.
BTW: Since I'm offering my opinion I should probably sign up to
help mentor. I won't have time to be full time mentor but would be
glad to help review patches.
TTFN,
Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html
On May 24, 2006, at 1:24 PM, Justin Mason wrote:
I'd like to hear people's experiences with SVK; my impression of
it (based
on its CVS support) was that it seemed pretty flaky. If that is
indeed
the case I wouldn't want to inflict it on the students...
(To be honest, I'm leaning towards an SVN branch for our student
projects
in SpamAssassin.)
--j.
Andrus Adamchik writes:
Heh, that's actually a more general problem with team development,
both open source and commercial. I've seen people who would not
commit their local work to CVS for weeks or months to postpone
dealing with integration issues :-)
So yes, communicating constant integration paradigm is important.
And
providing the right tools is what makes it practical.
Andrus
On May 24, 2006, at 2:21 PM, Garrett Rooney wrote:
On 5/24/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
It looks like recommending SVK per Kevin's SVK suggestion is a
good
idea - there won't be a need for the external repo, and it will
remove the reviewing bottleneck from the patch process.
Just be sure that you don't end up with the student doing all their
work locally and not showing it to anyone until it's done. That
totally defeats the point of open development, peer review, etc.
-garrett
