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

Re: Switching Bug

From: Donald H Locker <donald.locker_at_ptmelec.com>
Date: 2006-06-25 02:09:20 CEST

Has anyone found a resolution for or had any suggestions regarding this
issue.

I have a working copy with its knickers into a knot over this. We are
somewhat new to svn, but a coworker has been missing or ignoring failure
messages and blasting ahead, so we have wcs with mixed branch and trunk
connections. Which is driving me crazy as I'm doing the deployment and
maintenance for svn.

My clients are tortoise svn on Windust2k and XP boxes; FSFS repositories
on Win2k server; file/// access.

TortoiseSVN 1.3.3, Build 6219 - 32 Bit
Subversion 1.3.1,
apr 0.9.7
apr-iconv 0.9.7
apr-utils 0.9.7
berkeley db 4.3.28
neon 0.25.4
OpenSSL 0.9.8a 11 Oct 2005
zlib 1.2.3

The worst situation right now is a wc that is deep in the tubes. There
are many .svn/tmp/text-base/....svn-base files that don't exist in a
clean checkout-from-the-trunk-and-switch or from just a checkout from
the branch. I think I've recovered whatever changes coworkers have made
in that branch, but I don't know how many ended up in the trunk.

$ svn cleanup .
svn: In directory '.'
svn: Error processing command 'delete-entry' in '.'
svn: Working copy 'Drivers' is missing or not locked
$ svn lock Drivers
svn: Working copy 'C:\TesterV1 V4.09Xperiments' locked
svn: run 'svn cleanup' to remove locks (type svn help cleanup' for details
$ svn revert Drivers, svn rm Drivers, svn update Drivers all return
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type svn help cleanup' for details

TIA,
Donald.
(and I really like svn and TortoiseSVN; just wish I knew more about the
innards.)

Rob Jones wrote:
> Hi
>
> Ran into a problem switching from one branch to another yesterday.
> This left me with a src tree partly in one branch and partly in another.
>
> In principal if you have an uncommitted file in your branch when you
> switch from one to another this uncommitted file is left where it is.
> It is not deleted but it does not become added to the new branch,
> it is just a uncommitted file in the same place.
> This is also true for directories.
> However beware having uncommitted files inside new directories
> that are committed, or even just directories that exist in one branch but not another.
>
> Basically I can replicate the problem I had by having two branches A, and B
> initially the same, include a file called "xfile.txt" and have the newsubdir
> come before it alphabetically.
> In branch A I create
> newsubdir
> newsubdir/subsubdirA
> newsubdir/subsubdirA/fileA.txt
> newsubdir/subsubdirB
> newsubdir/subsubdirB/fileB.txt
>
> I then commit
> newsubdir
> newsubdir/subsubdirA
> newsubdir/subsubdirA/fileA.txt
> But leave
> newsubdir/subsubdirB
> newsubdir/subsubdirB/fileB.txt
> Uncommitted. (ie unversioned)
>
> When I then switch there is a rather ambigous message along the lines of
> "Wont delete locally modified directory, left locally modified or unversioned files"
> But what this doesnt say is that the switch was killed at this point.
> All files processed up to this point are in one branch, all those that would be processed
> after are in the original branch still.
>
> The directory in question is marked as in conflict but the problem is that any files
> after it are left untouched.
> Examining the properties on the root dir shows branch B,
> but examining xfile.txt shows branch A
>
> I would expect something along the lines of
> A) A check before anything is actually switched that then prompts the user along the
> lines shown, asking them to commit or remove unversioned files.
> B) Rollback to original state if this encountered
> or most prefferred
> C) Continuation of the switch leaving just the one problem directory marked as conflicting
> and everything else actually switched. The prompt should probably have
> "directory x contains conflicts" added to it to clarify things.
>
> I am not a member of this list but I am submitting this so that my findings are known,
> feel free to contain me directly if you need.
>
> Rob
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>

-- 
Donald H Locker
PTM Electronics, Inc
734 426 9010
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jun 25 02:12:49 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.