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

Re: design document

From: Hyrum K. Wright <hyrum_at_hyrumwright.org>
Date: Fri, 29 May 2009 08:40:50 -0500

On May 29, 2009, at 8:31 AM, C. Michael Pilato wrote:

> yellow.flying wrote:
>> **>I wasn't anticipating the change you seem to be proposing, where
>> the
>>> committables are grouped by working copy.
>>> My redesign of the commit process long ago assumes no need to group
>>> committables by working copy, only by repository. Commits are
>>> driven based
>>> on the committable's URL today -- *not* based on its working copy
>>> path.
>> I see that the committing files are still grouped by working copy
>> in native
>> implement of commit now, but it can be extend to group by
>> repository. So
>> if "committables" you design can deal with the later situation, I can
>> reuse it.
>> you say "no need to group committables by working copy, only by
>> repository",
>> do you mean that "base_dir_access" in the following function is not
>> necessary
>> a working copy access baton but a access baton to the base
>> directory of
>> several working copies from the same repository?
> I had forgotten about the access baton situation. (Actually, I
> think my
> code was written before we had access batons ... it was the addition
> of the
> access baton paradigm that made this all stop working, if I recall
> correctly.)
> Could this be as simple as adding a pointer to a working copy access
> baton
> to the committable structure, plus a master array of top-level
> working copy
> access batons (for post-commit releasing)?

Access batons are slowly disappearing from internal use in the working
copy library, and will hopefully go extinct in the client library as
well. In the future, we will just use a single svn_wc_context_t,
instead of carrying around a collection of access batons. I don't
know how this will impact the problem at hand, but it's good to keep
in mind.

Because this work is pretty tightly coupled to the working copy, I'd
encourage whoever is coding and reviewing it to closely follow any
public API changes made to libsvn_wc.


Received on 2009-05-29 15:41:30 CEST

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