SVN reports that all targets are not part of same working copy when there is an svn:external that points within the repository

[Ryan J Ollos <ry...@physiosonics.com>]

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:

svn: E155004: Commit failed (details follow):
svn: E155004: Are all targets part of the same working copy?
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

I've created a batch file [2] to reproduce the issue, using svn and svnadmin
from [3]. Just copy the text into a .bat file and drop it in a directory
with svn.exe and svnadmin.exe.

The versions I used to produce the error are:
svn, version 1.7.0-dev(r1088319)
svnadmin, version 1.7.0-dev(r1088319) 

[1] 
http://old.nabble.com/TSVN-reports-that-all-targets-are-not-part-of-same-working-copy-when-there-is-an-svn%3Aexternal-that-points-within-the-repository-td31103921.html

[2]
SET ROOTDIR=%cd%
SET REPOS=TestWorkingCopyWithExternals
SET REPOS_PATH=file:///%ROOTDIR%/%REPOS%
SET WC=%REPOS%-wc
SET SVN=%ROOTDIR%/svn.exe
SET SVNADMIN=%ROOTDIR%\svnadmin.exe

IF EXIST %REPOS% rmdir /s /q %REPOS%
IF EXIST %WC% rmdir /s /q %WC%

%SVNADMIN% create %REPOS%
%SVN% co %REPOS_PATH% %WC%
cd %WC%
mkdir proj1 proj2
%SVN% add proj1 proj2
%SVN% propset svn:externals "^/proj2 proj2" "proj1/"
%SVN% ci -m "" proj1 proj2
%SVN% up

echo proj1 > proj1/file1.txt
echo proj2 > proj2/file2.txt
%SVN% add proj1/file1.txt proj2/file2.txt
%SVN% ci -m ""
%SVN% up

cd proj1
echo > file3.txt
echo > proj2/file4.txt
%SVN% add file3.txt proj2/file4.txt
%SVN% ci -m "" file3.txt proj2/file4.txt
cd ../..

[3]
http://nightlybuilds.tortoisesvn.net/latest/x64/small/
-- 
View this message in context: http://old.nabble.com/SVN-reports-that-all-targets-are-not-part-of-same-working-copy-when-there-is-an-svn%3Aexternal-that-points-within-the-repository-tp31374552p31374552.html
Sent from the Subversion Dev mailing list archive at Nabble.com.

RE: SVN reports that all targets are not part of same working copy when there is an svn:external that points within the repository

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
> Sent: woensdag 13 april 2011 16:06
> To: 'Mark Phippard'
> Cc: 'Ryan J Ollos'; dev@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


> 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.

I implemented the lock calculator: Committed in r1091928.

So issue #2381 is fixed properly for 1.7.0 (including for commits from
multiple independent working copies on multiple drives on Windows)

	Bert

RE: SVN reports that all targets are not part of same working copy when there is an svn:external that points within the repository

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: Mark Phippard [mailto:markphip@gmail.com]
> Sent: woensdag 13 april 2011 15:24
> To: Bert Huijben
> Cc: Ryan J Ollos; dev@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 <be...@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

Re: SVN reports that all targets are not part of same working copy when there is an svn:external that points within the repository

[Mark Phippard <ma...@gmail.com>]

On Tue, Apr 12, 2011 at 5:16 AM, Bert Huijben <be...@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.

> Which leaves issue #2381:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2381 "Cannot commit
> multiple WC paths which lack a common parent directory"
> (And issue #2563, which has been marked as a duplicate of this issue)
>
> A feature/enhancement request which asks to make subversion capable of
> committing to multiple working copies at once.

This is another must-have for Subclipse.  We currently have a hack in
place that we use to make this work.  If the hack does not work with
1.7 ( have not tried it ) then we will get a ton of complaints about
this.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: SVN reports that all targets are not part of same working copy when there is an svn:external that points within the repository

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: Ryan J Ollos [mailto:ryano@physiosonics.com]
> Sent: dinsdag 12 april 2011 0:36
> To: dev@subversion.apache.org
> Subject: SVN reports that all targets are not part of same working copy
when
> 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.

Which leaves issue #2381:
http://subversion.tigris.org/issues/show_bug.cgi?id=2381 "Cannot commit
multiple WC paths which lack a common parent directory"
(And issue #2563, which has been marked as a duplicate of this issue)

A feature/enhancement request which asks to make subversion capable of
committing to multiple working copies at once.


As far as I can tell nobody is currently working on this, but it's not
really hard to implement this properly now.

(There was a quick and dirty implementation some time ago, but the new wc
library makes it much easier to implement this properly)

> svn: E155004: Commit failed (details follow):
> svn: E155004: Are all targets part of the same working copy?
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)

I don't like that final message in the error: A failed commit should just
release the locks properly.

	Bert