[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: A "Hello" from a GSOC volunteer

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Sat, 22 Mar 2008 11:22:24 -0400

"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?




(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


> 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



You might also want to look through our bug tracker:


...and see what other issues interested you.

Good luck,

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

This is an archived mail posted to the Subversion Dev mailing list.