You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Junjie Peng <pj...@gmail.com> on 2008/03/22 07:04:39 UTC
A "Hello" from a GSOC volunteer
Hello, everyone！
My name is Junjie Peng, you can call me Junjie. I'm a postgraduate in
Chinese Academy of Science. CS is my major. Last year I developed a
handphone map client on j2me when I acted as an intern in a company in
Beijing. It runs well on Nokia s60 products(E50 and 6300 are my testing
model). You can use it for browsing a map for a city, searching POIs such as
restaurants then getting the deep info and searching bus lines. But it is
limited heavily for the location APIs aren't open to common cellphones in
China now. I played the main role of this project. In this project,I
developed a Log tool for j2me cellphones and it simplified our latter works
greatly. In a considerable part of my work, I tried different strategies to
exploit the ability of the connection limited devices, such as compressing
and decompressing the data of maps and pois, and bringing a sliding window
to improve the read efficiency. I have harvested a lot from this project,
including SVN, unit testing, agile development (especially Test-Driven
Development) and some knowledge about Geocoding.
It was my first time to touch a version tool. SVN gives us a good
efficiency. I enjoyed it! I wish to be accepted for GSOC by Subversion. I
expected to get a deep knowledge of version control tools, gain experience
about software framework, and improve its performance for world-wide range
of develops.
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.
However, I'm not familiar with the source code of SVN. Besides, last year, I
enjoyed SVN through the eclipse plug-in, so I have few experience on CUI of
SVN. It also needs time and your help to conquer it.
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!
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.
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.
It's exciting to writing this letter for me, hope for your replies and
instructions!
Good luck!
Junjie Peng
Re: A "Hello" from a GSOC volunteer
Posted by Karl Fogel <kf...@red-bean.com>.
"Junjie Peng" <pj...@gmail.com> writes:
> 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.
Great, we look forward to hearing from you!
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A "Hello" from a GSOC volunteer
Posted by Junjie Peng <pj...@gmail.com>.
2008/3/22, Karl Fogel <kf...@red-bean.com>:
> "Junjie Peng" <pj...@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
Re: A "Hello" from a GSOC volunteer
Posted by Karl Fogel <kf...@red-bean.com>.
"Junjie Peng" <pj...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org