"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
(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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-22 16:22:34 CET