Are you sure you have your environment set up correctly? I usually have 3 or 4 branches checked out at any given time because I’m doing code reviews for people. And on top of that I often check out to a Windows machine just to compare. I have not seem any issues.
I just did a quick test and found the following reference in the project file:
Class=Class1;External/Class1.xojo_binary_code;&h1672B7FF;&h0;false
Class=Class2;…/Dummy/Class2.xojo_binary_code;&h48A57FF;&h0;false
Class 1 is in folder called External within the project folder
Class 2 is in a folder called Dummy at the same level as the project folder.
All relative.
Strange… I’m working with a main project in xojo_binary and external items in a mixture of binary and xml.
When I do a copy of the project and the external items and try to open the project on the second computer without having Wifi on it takes a long long time to open, because Xojo tries to find the external items on the first computer.
When doing a save then the project items are saved on the first computer even if I work on the second computer.
That is the problem - binary does not play with well with SVN
Exactly, Text format is what should be used for version control.
Still the absolute paths are so very strange.
When the pain of the binary format becomes too large I’ll think about switching. So far my setup worked well.
So what is the best practice?
Don’t use binary format. In addition to the problems already described you also end up being unable to use the most power features of SVN: Identifying which differences were made when, reverting individual changes to files etc…
@James Dooley is totally right. SVN makes nearly no sense with Binary Projects. It works, but has no real advantage. You degrade the SVN to an incremental Backup System, kind of. 
Thanks but my original question was about best practices when dealing with branches:
[quote]
What is the best practice when working with “branches” and your local working copy?
If you need to make a change in a branch should you just “switch” your local working copy “trunk” to that branch…make the change…commit and then switch back to your trunk?
Or should you “check out” the branch in a new directory so you effectively have two local working copies on your machine… the trunk and the branch?
Do developers sometimes keep two local copies in this way if they are continually making changes to their trunk and a release update branch for example?[/quote]
Why would you need to, it just makes things more complex and runs the risk of screwing up the check ins.
I don’t know about best practices, but at our work we do our development in the trunk and create a branch when we do a release.
This way if we need to patch a released version, we temporarily switch to the branch and make the necessary changes. Then we can create another build from that branch. We then switch back to the trunk and move the changes from the branch to the trunk. We then continue working in the trunk.
Might not be best practice, but that is what we do over here.
Dirk: So when you switch to the branch, do you just update the single local working copy from the trunk to the branch (so it basically just downloads the diff changes) … or do you check out the branch in another directory so you have two local working copies … the trunk and the branch?
We’ve used the two methods. I myself prefer switching to the branch overwriting my local copy with the branch. That way there is only one working copy and I find that less confusing.
Some of my colleagues prefer checking out the branch in a separate folder. You then have two local copies of the same project, one is the branch and the other one is the trunk. I find it hard to see at a glance what version I have open when I work this way, so I prefer one copy that is either branch or trunk.
I guess it boils down to personal preference.
Thanks. Would be good to get some votes on this perhaps?
Option 1: “Switch” and one working copy
Option 2: 'Check Out" and two working copies
What method do you use?
1
I use option 2
SmartSVN is driving me nuts!
So I created my first test release branch and tag 1.0.0.
I then “switched” to this new branch and made some minor changes (adding a button and “hello world” msgbox) to the window and comitted those changes to the branch and the local working copy.
I then switched back to the trunk and updated it to make sure everything was correctly in sync with the repo.
I then tried to merge the branch (all revisions) back into the trunk and it doesn’t work.
I ran the merge preview and basically every top level folder in the preview window has a red folder icon with a break in it which according to the manual (http://www.smartsvn.com/doc/display/SU/Directory+Tree+and+File+Table) means:
“Obstructed: A directory exists locally, but according to the pristine copy (i.e. the information from the repository) it should be a file. Please backup the contents of the directory, then remove it and update the file from the repository”
I ran a query file/directory compare between the trunk and the branch and this correctly just shows the single changed window element of the project (which had the new button on it).
What’s more the merge preview takes about 5 minutes to run before it displays.
Surely either SmartSVN is crap or I’m doing something wrong because source control shouldn’t be this difficult.
Any advice?
I’m using SmartSVN here. Make sure the top level of your working copy and where you are mergin from are identical. For instance, if you’ve got the xojo_project file at the top level of one, it has to be at the top level of the other.
I’m also going to suggest that you try not using Switch. I know this is what it’s for, but in all the years I’ve used svn, I’ve found that having a second working copy on the drive is just a lot easier to problem I used to have was that I’d start working on code without understanding what my working copy currently pointed to and get things checked into the wrong place.
Hi Greg. They are absolutely identical.
As explained I began with a single working local copy of my Xojo project. I then created a branch and switched to it staying in the same folder I was before. I made some changes, committed them and then switched back to the trunk.
All the time I have stayed in the same local working copy folder manipulating the exact same files. Apart from the .svn folder only the window file had changed since that was where I put the button.
There is absolutely no reason for any conflicts.
And FYI: I tried first by checking out a working copy for the branch in another directory (outside of the trunk) and that didn’t work either.
Also, on the merge window if you click on the broken red folder all the other files within it are red and say that the state/content/properties are all “modified”… but they have not been.