Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of
 prvs=937943902=Andrew.Reedick@cbeyond.net designates 69.199.69.197 as
 permitted sender)
From: Andrew Reedick <Andrew.Reedick@cbeyond.net>
To: John Maher <JohnM@rotair.com>, Subversion help
	<users@subversion.apache.org>
Date: Tue, 20 Aug 2013 16:02:26 -0400
Subject: RE: Switching
Thread-Topic: Switching
Thread-Index: Ac6dAeCmrpSdVW6lT1iVVIVXpXzUJwAp+KnAAAYozyAABiV0sA==
Message-ID: 
 <1B05D8F50421E24799AE93B03CC284BE01CAFDB285@CRPMBX01.corp.cbeyond.net>
References: <910250F21FAA2A4E8F72DD21EA7807660906148C@VMJudi.corp.rotair.com>
 <1B05D8F50421E24799AE93B03CC284BE01CAE9CCEB@CRPMBX01.corp.cbeyond.net>
 <910250F21FAA2A4E8F72DD21EA78076609065B00@VMJudi.corp.rotair.com>
In-Reply-To: <910250F21FAA2A4E8F72DD21EA78076609065B00@VMJudi.corp.rotair.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


> -----Original Message-----
> From: John Maher [mailto:JohnM@rotair.com]
> Sent: Tuesday, August 20, 2013 1:33 PM
> To: Andrew Reedick; Subversion help
> Subject: RE: Switching
>=20
> Thanks for your reply.  I agree it does not make sense.  But it is
> reproducible.  The dir trees are NOT identical because one branch has a
> library that the other does not.  In normal use I would expect the
> branches to differ.  And I assure you one of the branches does not have
> the directory causing the trouble, I checked on the server.
>=20
> So the branches are different and it appears impossible to switch
> between them without conflicts.
>=20
> For example, when I switch to branch P it switches OK.  An svn status
> on the problem directory shows it with a '?'.  Then I switch to branch
> E and get a conflict.  It says "local unversioned, incoming add upon
> switch".  The local should be unversioned, it is not part of branch P.
> I do not know why the directory did not get deleted during the switch.
> An svn status shows the directory marked for deletion.  So in one
> instance of time I get a message of a directory that is unversioned,
> incoming add, marked for deletion.

When removing dirs, switch will not delete local/private/unversioned files.=
  If there is a local file in a dir tree, then all the versioned files will=
 be removed from your workspace, but a local tree will remain with the loca=
l files still in it.  That's mostly likely why you see a '?' after the swit=
ch.

Ex:
1. 'this_dir' exists in current workspace as a versioned dir tree.
2. 'this_dir' does NOT exist in branch P.
3.  touch this_dir/hello_world.txt
3.  svn switch ^/branches/P
4.  svn status:  " ?       this_dir"
The only file under "this_dir" will be hello_world.txt.  All other versione=
d files/dirs will have been removed.

>=20
> Svn revert does not do anything useful.  So I then issue svn resolve --
> accept working UI_Email where UI_Email is the directory causing the
> problems.  This clears the conflict.
>=20
> Then I switch to branch P.  Then is says "local delete, incoming
> delete".  Why it has a local delete is beyond me.  That folder is part
> of the branch, I want it there and never issued a delete.  But
> subversion did.  So I resolve this conflict the same as the last one
> and switch back to branch E.  You guessed it, conflict again.

You shot yourself in the foot.  =3D)

The local copy of the dir prevented switch from running the add.  (Switch w=
asn't able to pull in the versioned copy of the dir.)  Then you didn't fix =
the dir conflict by manually running 'svn copy' yourself to pull in the dir=
 from branch P.  When you did the resolve, you told svn that the current st=
ate of the dir is correct, and since the current state of the dir was effec=
tively "deleted", you wound up telling svn to delete the file from branch P=
.

Again, when resolving tree conflicts, you need to manually copy/add/delete/=
mv manipulate the tree into the correct state before resolving the tree con=
flict.


>=20
> So I resolve the conflict then commit and decide to let subversion
> delete the directory (I have a backup because I've lost code to
> subversion before).  So now my code is gone.  I delete the directory
> with supporting files.  Then I switch to branch P.  Success for now (I
> know failure is just a matter of time).

You can recover the deleted versioned dirs and files via peg revisions.  ht=
tp://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.=
branchmerge.basicmerging.resurrect

=20
> Then I switch to branch E.  No conflict.  But I won't get my hopes up
> yet, I still do not have the new library included which was the whole
> reason for creating the branch in the first place. =20

Right.  You deleted the dir from branch P.  And you deleted the local/priva=
te files/tree as well.  Thus no conflict with branch E.

However, if you want to get the dir into branch E, then you should have mer=
ged from branch P to branch E (or used 'svn copy ^/branches/P/some_dir ^/br=
anches/E/some_dir.)  (But you'll need to restore the dir in branch P first =
via 'svn copy' and a peg revision.)


> So I copy over the
> directory and do a svn add then commit.  Then I can switch to branch P.

Argh.  No, no, no.  That creates "evil twins".  What you should have done w=
as 'svn copy svn://..../some_dir@1234 some_dir" to add the dir back in.  Wh=
en you run 'svn add' you create brand new objects with no history.  Evil tw=
ins break merging. =20


> This is where the problem arises.  Subversion deletes the files but not
> the directory because it contains files that do not belong in
> subversion.  I have no control over this as the compiler puts them
> there.  They are on the global ignore list.

Svn switch won't delete your local/private files because that would be rude=
, where rude equals "destroying the user's files."  So if you're switching,=
 you need to manage private/local files.  Maybe run 'make clean' (assuming =
you have a clean option) before switching?  Or tweak your build script to p=
ut all build output in its own dir, instead of putting output in the versio=
ned dirs?