> -----Original Message-----
> From: Mark Phippard [mailto:markphip_at_gmail.com]
> Sent: woensdag 13 april 2011 15:24
> To: Bert Huijben
> Cc: Ryan J Ollos; dev_at_subversion.apache.org
> Subject: Re: SVN reports that all targets are not part of same working
copy
> when there is an svn:external that points within the repository
>
> On Tue, Apr 12, 2011 at 5:16 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
> >> there is an svn:external that points within the repository
> >>
> >>
> >> I originally reported this issue with TortoiseSVN [1], but we narrowed
it
> >> down to an issue in Subversion 1.7dev.
> >>
> >> If I am committing a working copy with modifications to dir1 and dir2,
> > dir2
> >> being an svn:externals directory that points to a location *within* the
> >> repository, I get an error that I didn't see with SVN 1.6:
> >
> > Subversion 1.5/1.6 didn't do proper lock checking when committing, which
> > allowed you to commit nested working copies when a few preconditions
> where
> > true. (I reported this issue with some examples on how this could
corrupt
> > your working copy beyond repair when we were working on Subversion
> 1.6).
> >
> > The new working copy library isn't as sloppy as the old working copy
library
> > (aka WC-)1.0 and correctly detects that the files are not in one working
> > copy and aren't locked.
>
> I do not understand this answer. You seem to be saying that you
> consider the current behavior a bug that has been fixed? I know in
> Subclipse we rely on the current behavior and if it has changed then
> it is going to be a problem. Specifically, I am referring to a WC
> where you have externals that come from the same repository. In
> Subclipse, we are able to commit all these changes in a single atomic
> commit and that is what users want. If we cannot do this any more we
> are going to get lots of complaints.
Yes, the 1.6 behavior is a certainly bug that has been fixed.
(When I tried to enable this in AnkhSVN a few years ago I destroyed working
copies this way...)
We didn't check if an access baton was locked before processing the commit.
(The older code always locked recursively. Once depth was introduced in 1.5
the assumption was kept, but the lock removed)
And yes I intend to implement it properly well before 1.7, but most likely
not before the end of this week.
Resolving this issue cleanly should be easy once I'm done cleaning up the
commit harvester.
Bert
Received on 2011-04-13 16:06:57 CEST