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

Re: [PATCH]svn_wc__find_wc_root

From: Stefan Sperling <stsp_at_elego.de>
Date: Sun, 28 Jun 2009 17:28:34 +0100

On Sun, Jun 28, 2009 at 10:29:32AM +0800, yellow.flying wrote:
> >So I think we'll need to change the logic.
> >Let's start again from the top.
>
> >Recall again what we want to achieve:
>
> >== Goal ==
> >We want to get a set of access batons, one for the root of each
> >working copy involved in a commit. As input, we get a list
> >of paths that are part of an arbitrary amount of working copies.
> >We also want to group those paths by their working copy root.
>
> >Then we want to make a commit from each working copy root.
>
> >Doing a single commit for all working copies at once is too hard.
> >See svn_client__do_commit and follow the use of its base_dir_access,
> >which is the root of the working copy the commit is made from.
> >There is so much code that assumes a single access baton for
> >the root that you would run out of time for your gsoc project
> >before you are anywhere near done changing it all.
> Actually what I want to do is to do a single commit for all working
> copies from one repository. It is a little differcult for me right now,
> and I am tring my best but not sure whether I can finish it before
> deadline of GOCS.

OK, you pick your own goals. It's of course great if you can achieve that.

But you'll need to group commit targets per working copy anyway,
no matter whether the final result is a single commit or multiple
commits. So the "new plan" is clearly the first step, no matter
whether you later decide to make separate commits or one big commit.

> I have saw the purpose of GOCS you write, these days there are
> lots of controversy on my work, and I know that my work may not
> be used in subversion. So I think the most important thing for me is
> to be familiar with subversion code and Writing code is a way
> to achieve this goal. This is preparation for my future work on
> subversion and I wish I can work on subversion for a long time.
>
> Do I understand the right thing?

Yes. The only way to get good at fixing problems in Subversion
is hacking it. Initially it does not even matter if your code
will really be used. The first thing I did with Subversion code
was never used, either. But it helped me a lot.

> >== What's there now ==
> >Currently, the code "condenses" all target paths, which means it
> >tries to find a common root for them, and then it tries to lock that
> >common root. If the common root is not a working copy, locking the
> >common root fails and the commit is simply aborted ("svn: <common root>
> >is not a working copy").
>
> >== What we can do instead ==
> >So let's say we did the following instead of aborting the commit:
>
> > If locking the common root failed:
> You mean we failed at this line, right?
> SVN_ERR(svn_wc_adm_open3(&base_dir_access, NULL, base_dir,
> TRUE, /* Write lock */
> I know it may be a littel trivial to ask these kind of details, I just
> want to make sure that I understand the right thing.

Exactly. That's where the code is trying to lock the "common root".

> > For each target path we got:
>
> > For each working copy root we already know (initially we don't
> > know any working copy roots):
> > Check if the current target path is below the working copy root.
> > If it is, put it into this root's group ("commit packet")
> > and continue with the next target path.
>
> > If we end up here, no suitable working copy root was found
> > for the current target path.
> > Walk the current target path downwards, starting from the common
> > root (the root which we could not lock).
> Do you mean 'common root' as base_dir here?

Yes. Currently, there can only be one base_dir.
But we need one base_dir per working copy.
  
> > Try to lock the current directory at each step.
> > If locking succeeds, we have found a new WC root!
> > Store its access baton in the set of known working copy roots.
> > Put the current target path into the group of the root we just found.
>
> > Now run a commit for each working copy root we found.
> > This is done just like before when the code only knew about
> > a single root, but it's done for each root in turn.
> So I can reuse original code to commit for each root, right?

Yeah. You can try to get "one commit per working copy" working first.
Because that is the easiest way of solving issue #2381, though it's
not perfect. Let's call this "solution 1" (like in my email to Philip).

Once you have solution 1 working, you can change it into "solution 2",
which is "one single commit for all working copies".
The work you will have done for solution 1 will help you with solution 2,
because solution 2 also requires you to group all commitables by
working copy.

And you will have more experience with the code. Solution 1 can be done in
just one file, libsvn_client/commit.c. Solution 2 will require
modifications to several files in libsvn_client/, and you will need
to understand the entire commit code much better than you (and I) do
now.

> > Also, make svn_client_commit() return an array of svn_commit_info_t
> > objects, one for each commit made, instead of just a single
> > svn_commit_info_t object.
>
> >If you agree to this plan, I'm sorry that your current
> >svn_wc__find_wc_root() patch might not be committed after all.
> >But at least for me, the patch helped me a lot to actually
> >understand the problem :)
> That is Ok, I have learnt a lot by writing this patch, too.:) What I have
> learnt is the true progress I make, isn't it?

Yeah :)

> >Should we update the notes/ file with the new plan?
> After I am clear of the new plan detaily I will update the notes/file.

Great!

Have fun,
Stefan
Received on 2009-06-28 18:29:04 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.