Hey Stefan,
I am attempting to read the header files indicated in the "Code to Read"
section. It is really a hard work and I just know the general functions of
each file but not the detail.
Thanks for your suggestion and Mark‘s comment. I have tried 'svn commit'
command on my machine, too. And the following is the first two parts of
design document as you suggest. If there is any misunderstanding, please
let me know.
1) Expected behaviour
-- Describe what you want Subversion to do.
When committing files, listing their paths, no matter whether they belong
to the same work copy or not, if they all live in the same repository, they
should be committed in one transaction successfully.
2) Actual behaviour
-- Describe what Subversion currently does instead.
If the committing files belong to the same work copy, they will be committed
in one transaction successfully.
Otherwise, if they belong to more than one work copy, svn will output an
error which indicate that their common ancestor is not a work copy and
commit action fails.
I am reading the original implement of 'commit' action. I think only when
I have finished this part, I would know what changes should be made.
I hope I can make the original implement and the implement in SVNKit
of 'commit' action clear next week. Then I will give out the third part of
design document as soon as possible and discuss with you guys. I will
try to finish these work before June 7(at least not later than June 14 as
planed in my proposal, actually I hope there is enough time to discuss the
design document). And then I will begin to code.
I know that you are busy with exams these days and I have exams too, so
I do not send mail to you. But do not worry about the time, I will finish my
exams soon. I hope you will do well in your examinations.
I will conclude every week's work on the weekend and send the conclusion
to you by email since next week.
Good Luck!
Hui Huang
2009-05-22
yellow.flying
发件人： Stefan Sperling
发送时间： 2009-05-22 06:48:27
收件人： HuiHuang
抄送： dev
主题： [gsoc] We need to design "commit from multiple working copies"
Hey HuiHuang,
According to the GSoc schedule, coding should start at the 23rd
of May, which is in 2 days! I hope you are ready to go :)
I have not seen mail from you on the dev list about your project
yet. And I could not be in IRC much lately so I don't know if you
were active there?
Anyway, I just wanted to help you get going.
It would be great if you could start by discussing your project
with the community. You could explain how you are planning to
implement the "multiple working copy commit" feature and discuss
this plan with others.
This is very important, because for every new feature there
needs to be a detailed design proposal that everyone in the
community can look at. The design of the feature needs to be
well understood before you can really start coding, and getting
the design correct might take some time.
I found a very interesting comment by Daniel Rall in issue #2381:
http://subversion.tigris.org/issues/show_bug.cgi?id=2381
Here is what Daniel said:
Expected behavior:
If I commit files, listing their paths, and they all live
in the same repository, I would expect the commit to succeed
and do it one transaction.
Actual behavior:
Subversion errors out if you try to do this. As a workaround,
Subclipse has to break this up into multiple commits. Users feel
like they are losing a key Subversion feature.
Suggested change:
The JavaSVN/SVNKit library added support for this. In their case,
we just have to give them all the paths, and they break it up into
one commit per repository. I would be happy doing this break up in
Subclipse, if I could just get the single commit to work when they
are all in the same repository.
I think Daniel's comment is a very good start for a proper design
proposal for these reasons:
First, it provides a rough structure for your design document:
1) Expected behaviour
-- Describe what you want Subversion to do.
2) Actual behaviour
-- Describe what Subversion currently does instead.
3) Suggested change
-- Describe how you want to change Subversion to make
the expected behaviour happen.
Second, Daniel points out that the problem has been solved in SVNKit.
I don't really understand how they solved it from reading his comment.
However, this is still very useful information because it gives us
one working example of how the problem can be fixed. In case you
didn't know, SVNKit is an implementation of Subversion written
entirely in Java. Their website is http://www.svnkit.com
SVNKit is also an Open Source project, which means that we can look
at how their fix for the problem has been implemented. I think you
should definitely try to find out how exactly they solved the problem.
You can browse the SVNKit source code here:
http://svn.svnkit.com/repos/svnkit/trunk/
I think your design proposal should include a section describing
how the problem was solved in SVNKit. For example, you could
split up section "3) Suggested change" into two sections:
3a) SVNKit's solution
-- Describe how SVNKit behaves, and how they implemented
this behaviour.
3b) Suggested change for Subversion
-- Describe how you want to change Subversion to make
the expected behaviour happen.
Looking at SVNKit's solution should give us insight into the problem.
Maybe we can use the same idea. Or maybe we can come up with an even
better idea. In any case, I think looking at their solution should
provide a good starting point for your project.
See you,
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2352733
Received on 2009-05-22 04:56:57 CEST