On Fri, Jun 26, 2009 at 04:17:03PM +0100, Philip Martin wrote:
> Philip Martin <philip_at_codematters.co.uk> writes:
>
> > Stefan Sperling <stsp_at_elego.de> writes:
> >
> >> Again, they're not going to multiple repositories, they're going
> >> to the same repository. The goal is to save the user the surprise
> >> of getting "svn: <common root> is not a working copy" when svn
> >> could just do a separate commit for each.
> >
> > Really? If I ran "commit foo/bar foo/baz" expecting one commit and
> > got two commits I would be tempted to file a bug. Is getting two
> > commits instead of an error better? Should there be a command line
> > option to enable multiple commits?
>
> I usually use -F to pass log messages. How does that work with
> multiple commits? Will you just repeat the log message?
I think you're missing the point of Summer of Code.
Let's look at the alternatives again:
1) Do the easy solution which isn't perfect at all but allows
a Gsoc student to get his feet wet with Subversion code.
Most people won't like it and it will probably never end up
in a Subversion release. The solution will be discarded
anyway later when commit functionality is rebased on WC-NG.
2) Try to change the current commit code into passing around a
list of access batons, and make it create truly atomic commits
from multiple working copies as people would expect. This solution
is much more involved than 1), so the gsoc student is much more
likely to get lost in the details and never finish the project.
People might like it, and it could even end up in a release if
WC-NG continues to progress at the current slow speed.
The solution will be discarded later when commit functionality
is rebased on WC-NG, even though it was much harder to achieve
than 1).
3) Start working on WC-NG instead of doing this in wc-1. A lot of
things are still left to do before svn commit will even start using
WC-NG code. So the GSOC project's goal will change from "allow commit
from multiple working copies" to "help get WC-NG ready so that,
one day, we can have truly atomic commits from multiple working
copies". Hyrum tells me:
<hwright> frankly, there's still a bunch of magic that's happening
which I don't quite understand just yet.
<hwright> the difficulty is that the tasks are hard to quantify
<hwright> "a maze of twisty passages" probably best describes the
work thus far
<stsp> hmm
<hwright> I've started working on one thing and ended up with a
stack 6- or 7-levels deep, there's so much spaghetti code
<hwright> so I'm hesitant to claim that *any* task, even an apparently
trivial one, is really trivial
<hwright> now, do I think SoC-type stuff exists? certainly
<stsp> good
<stsp> what is it?
<hwright> but identifying it off hand is the problem :)
Now, I don't really care which alternative HuiHuang wants to pursue.
It's really up to him, but as his mentor I would recommend approach
number 1 for now because it is much, much easier to do than the other
two and still allows him to pick up the basics of Subversion hacking.
If he finishes 1) on time, he's reached his goal for GSOC -> Good!
If he even finishes 1) early, and there's still time left for the other
solutions, and he even wants to start working on them, good! We've just
gained another motivated developer, the true purpose of GSOC!
Recall that, so far, most of our GSOC students have *never* returned.
Hyrum being the only notable exception I can think of right now (sorry
if I missed anyone).
If you'd rather see a perfect technical solution, either wait for WC-NG
to be ready for it, or hack it yourself and show it to HuiHuang so
he can learn from that.
But instead of getting lost in Subversion's complexity, I'd rather see
HuiHuang successfully write a complete, but simple and consistent feature
with a known set of limitations. Even if we discard it later, having
achieved that is a good thing. If it is fun for him and raises his
appetite for more, then the goal has been reached.
Stefan
Received on 2009-06-26 18:32:38 CEST