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