Slowing code churn in libsvn_wc

[Karl Fogel <kf...@newton.ch.collab.net>]

This is a "meta request":

I haven't had time yet to carefully look at the lock problems in
libsvn_wc; I've read all of Philip's and Justin's discussion, just
haven't had time to really digest the discussion and inspect the code
for myself.  I don't think Ben Collins-Sussman has had time either,
nor has Mike Pilato.  This is a pity, because we three probably know
libsvn_wc best and would be the obvious people to review the recent
code changes (diffidence or false humility would be useless here, so
I'm not even going to bother).

So I'd like to request that until Alpha is released, we confine
ourselves to fixing bugs in the current libsvn_wc code, and not try to
make any more forward progress on issue #749.  The most recent commits
and patches to libsvn_wc have indeed been for fixing bugs, so my
request is pre-emptive, not reactive :-).

The problem is not that the commits are bad in themselves.  It's just
that the most qualified reviewers are temporarily very busy with other
Alpha issues, and these are commits that deserve full attention,
nothing less.  Therefore it makes sense to coordinate coding and
review times on this, until Alpha is out.

Thanks,
-Karl

Philip Martin <ph...@codematters.co.uk> writes:
> This patch implements a parent-child lock relationship.  It passes
> the regression tests, including Justin's new one.  I'm posting it to
> ask if this is the right way to go. One thing that worries me is the
> memory usage, it's probably trivial at the moment, but if we start to
> cache the entries will it prove to be too expensive?
> 
> Since my visitors' baby has stopped crying I'm going to try to get
> some sleep now :)
> 
> 
> Continuing issue #749. Make svn_wc_adm_access_t optionally
> hierarchical.
> 
> Also revert r2504 as it's no longer needed.
>
> [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Slowing code churn in libsvn_wc

[Karl Fogel <kf...@newton.ch.collab.net>]

Philip Martin <ph...@codematters.co.uk> writes:
> Perhaps we should revert 2470 as it introduces a regression. The
> second commit in the following sequence

Yeah, that's one of the options on the table.  Especially given your
recent comments in issue #792, we can't be certain that we fully
understand the cause of the Kevin's original commit bug either, except
that it appeared between 2452/2470 and 2504.

(So if we revert 2470, would we also then revert 2452, do you think?
I kind of think we should.  It feels odd to leave the half-started
change in the code; better if all this stuff were cleanly restarted
after Alpha, instead of awkwardly bridging the release.)

Anyway, let's wait a bit on making this call.  Ben is reproducing the
regression right now and taking a look, we'll come back with more
formal proposal for action in a bit.

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Slowing code churn in libsvn_wc

[Philip Martin <ph...@codematters.co.uk>]

Karl Fogel <kf...@newton.ch.collab.net> writes:

> So I'd like to request that until Alpha is released, we confine
> ourselves to fixing bugs in the current libsvn_wc code, and not try to
> make any more forward progress on issue #749.

Perhaps we should revert 2470 as it introduces a regression. The
second commit in the following sequence

$ svn mkdir foo
$ svn mkdir foo/bar
$ touch     foo/bar/zig
$ svn add   foo/bar/zig
$ svn ci
$ svn cp foo foo2
$ echo x >> foo2/bar/zig
$ svn ci

fails with "foo2/bar already locked".

> Philip Martin <ph...@codematters.co.uk> writes:
> > This patch implements a parent-child lock relationship.  It passes
> > the regression tests, including Justin's new one.

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org