On Fri, Apr 03, 2009 at 01:27:11PM +0200, Branko Cibej wrote:
> Dear devs,
>
> I'm looking at the SoC student proposals currently submitted for SVN,
> and quite frankly, I'm not thrilled ... (Yup, I know we didn't break our
> backs to get more proposals).
Let's please keep in mind that the applicants are young aspiring hackers,
and not thick-skinned grumps with years of experience in open source
like you. Many of them have never worked in open source and might
find it hard to digest blunt responses as they sometimes fly around
here.
> So let's take 'em one at a time:
>
> * Improve the Commit system for SVN (Penn Su)
> I haven't a clue what this is about, except that it's mostly about
> TortoiseSVN and, if you happen to dig deep enough, appears to
> propose the ability to commit unchanged files.
Yes, the purpose of this project seems to be to make unmodified
files appear as part of a commit transaction.
I don't think this idea is in harmony with Subversion's design.
A revision describes only the part of the tree that has changed.
Making files appear to be modified in a revision when the were
not modified in fact would confuse a lot of people. Probably
even more people than are confused by the way things are currently
working.
The student pointed to a mailing list post describing the problem
he wants to fix:
http://svn.haxx.se/tsvnusers/archive-2006-06/0155.shtml
but you can see from the replies to that post that there already
are workarounds for the problem.
> * Show progress output and diff in console (Penn Su)
> There's nothing here apar from references to the two issues in our
> tracker, and the cryptic "Personally, I think the output for diff
> should be updated. It is still confusing to me when I use diff in
> console".
Well, but in this case we have an issue (#901) we can refer to,
and it is pretty clear what that issue is about. We have this task
on our idea list. Other students have also applied for this task.
I agree that the comment about the diff output could be more detailed.
What is confusing about it and why? How could it be done better?
Without suggestions for improvements, the proposal is not very
constructive because it does not explain *what* will be done.
> * Integrate the ctypes python bindings into Trac (ashitosh darbarwar)
> This student proposes a project about packaging the ctypes python
> bindings and putting teaching Trac to use them. Whilst the
> packaging part is marginally related to Subversion (remember, we
> don't provide any official binary packages), the second part is
> about Trac, so sorry, that's another project.
Yes, I agree with that sentiment. Trac is outside the scope of our
project.
> * Apply for GSoC about ???Allow Commit from multiple working copies???
> (hui huang)
> Appears to be a reasonable proposal, except for the interesting
> idea that he'll burn through getting to know the SVN codebase,
> design and implementation (no mention of testing) in 3 weeks.
Yes, the schedule does not sound feasible. Subversion is most likely
more complex than hui huang is expecting.
However, we have this task on our ideas page. Whoever put it there
must have thought the task is feasible in 3 months time.
The proposal has a more detail than any of the above and describes
an initial idea of solving the problem.
In issue #2381 Daniel Rall pointed out that SVNKit have fixed this
problem. Maybe we can mirror their approach, whichever it is?
That would be a good start and should be a fairly safe approach.
> * Show progress output (Hao Zhang)
> This is a reasonable proposal, with extra points for discussing it
> in some detail on the dev list first.
Yes. This is a very good proposal, and has been communicated
on the dev list before, and results of this discussion have
been reflected in the proposal. Apart from actively talking to us,
Hao Zhang seems to also have familiarised himself with the Subversion
code base a bit already.
The problem is well understood and should be manageable in the given
time frame.
I'd be willing to mentor either this project or the previous one,
together with another developer. As I said before I cannot guarantee
availability during April and May because I'll have to sit exams myself.
One additional proposal has been filed:
* revision analyzer (Gang-Han Lee)
The proposal has been posted to the dev list, too. It is about representing
statistical information about commits graphically. I would not consider
this task part of Subversion itself. The proposal does not explain
how this task would be integrated into the Subversion core either.
Stefan
Received on 2009-04-03 20:20:13 CEST