2008/3/22, Karl Fogel <kfogel_at_red-bean.com>:
> "Junjie Peng" <pjj.ccce_at_gmail.com> writes:
> > I hope I will be eligible for GSOC. I'm familiar with java and C. I
> > have also developed some MIS with c#, asp.net, sql server. Besides, I
> > can perform well on Data Structure, and I am one of the chief
> > reporters in our college. I have read "Hacker's Guide to Subversion",
> > I would like to follow it's instructions in my development. In fact,
> > we did the same way last year.
>
> Thanks for inquiring! Have you read these two documents?
>
> http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_student_apply
>
> and
>
> http://subversion.tigris.org/project_tasks.html#summer-of-code
>
Karl, thank you for your reply! I have read the two links and gone
through the idea in the list posted before I wrote the first letter. :) In
my first letter, I described my stituations in detial to make sure Whether I
am eligible* for SVN* in this GSOC and what should I do to act better in
following months. Could I take more infomation?
> (The second one lists some GSOC ideas, but we welcome other ideas too.)
>
> > I have two ideas:
> >
> > 1.) Straight trace for items deleted and renamed. In SVN, take a file
> > for example, if it is deleted, it can not be checked out directly from
> > the project after twice commitment. It can only be checked out before
> > the point it was first committed. Projects, packages and directories
> > including projects have the same problem. In the familiar way, If it
> > is renamed, when committed, the log records as that the file is
> > deleted first and a file with new name added later. After twice
> > commitment, If we need browse the trace for the file before the rename
> > operation, we need check out the parent node including the file. It's
> > not a nature performance!
>
> This might be a bit hard for a summer of code project. Take a look at
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=898
> http://subversion.tigris.org/issues/show_bug.cgi?id=895
>
> > 2.) Remove the verbose update operation. Before checking in, we need
> > synchronize or update, it's easy to accept. But after a commitment,
> > it's necessary to update again immediately, otherwise a little
> > asynchronies will occur between the client and server. Maybe SVN
> > should update itself after the commitment.
>
> This we're probably not going to change, for compatibility reasons, and
> because not everyone wants it. (One could easily write a wrapper client
> to do the update anyway.)
>
> Even if we were going to make this change, it would not be a good GSOC
> project, because it would be far too easy: just add an "update" :-).
>
> > Maybe the two ideas are not so suitable for a GSOC idea. The first one
> > is a little simple; the second seems like a bug. I also like ideas in
> > the list posted. All of them point to a fact problem.
>
> The first one isn't as simple as you think, probably. The second one is
> deliberate design, not a bug (though I can understand how for some
> people it is not the ideal behavior). Note that fixing bugs is okay for
> GSOC, as
>
> http://subversion.tigris.org/project_tasks.html#summer-of-code
>
> shows.
>
> You might also want to look through our bug tracker:
>
>
http://subversion.tigris.org/issues/buglist.cgi?component=subversion&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&order=issues.target_milestone%2C%20issues.priority%2C%20issues.issue_type
>
> ...and see what other issues interested you.
>
> Good luck,
> -Karl
>
I have read the bug links you gave,I agree with you that It seems my
two ideas are not so suitable for GSOC projects. Thank you to advise
me to go through the bug tracker, I think it's a good way to get fresh
ideas as well as to give a proposal about the problems
we encountered at work and to know more about how an open-source project
works. Besides, I also like the ideas in the list posted, maybe I will
choose one from the list after more consideration.
Regards!
Junjie
Received on 2008-03-22 16:56:59 CET