RE: Switching

Thanks for your replies Andrew and Thorsten.

@Andrew there is no need for a svn copy. I do not want to copy a feature in one branch to another; I wish to keep the code isolated.

And yes I know subversion won't delete unversioned files, I appreciate the info on how subversion works. Some of it was helpful. I was hoping to hear how others may have solved the same problem. But it seems the only answer is a tedious and manual process for the simplest of enhancements.

I was hoping to find what others seem to praise, but have continually come up empty handed. I'll check stackoverflow before I give up.

Thanks anyway
JM

-----Original Message-----
From: Andrew Reedick [mailto:Andrew.Reedick_at_cbeyond.net]
Sent: Tuesday, August 20, 2013 4:02 PM
To: John Maher; Subversion help
Subject: RE: Switching

> -----Original Message-----
> From: John Maher [mailto:JohnM_at_rotair.com]
> Sent: Tuesday, August 20, 2013 1:33 PM
> To: Andrew Reedick; Subversion help
> Subject: RE: Switching
>
> 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.
>
> So the branches are different and it appears impossible to switch
> between them without conflicts.
>
> 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 local files still in it. That's mostly likely why you see a '?' after the switch.

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 versioned files/dirs will have been removed.

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

The local copy of the dir prevented switch from running the add. (Switch wasn'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 state of the dir is correct, and since the current state of the dir was effectively "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 conflict.

>
> 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. http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.resurrect

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

Right. You deleted the dir from branch P. And you deleted the local/private 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 merged from branch P to branch E (or used 'svn copy ^/branches/P/some_dir ^/branches/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 was 'svn copy svn://..../some_dir_at_1234 some_dir" to add the dir back in. When you run 'svn add' you create brand new objects with no history. Evil twins break merging.

> 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 put all build output in its own dir, instead of putting output in the versioned dirs?
Received on 2013-08-22 13:31:49 CEST