Socialpoints

I have experienced an annoying bug with switching my projects between SVN branches in eclipse.

It tended to freeze eclipse at the end of the swtich - forcing me to crash eclipse and restart.ﾠ

When I restarted eclipse I would generally find that the swicth had actually happened.

Anyway I have upgraded the subclipse plugin to the latest version 1.4.8 (update site here) and have now done 4 big switches with no freezing, hoorah!

It also seems faster - so thanks subclipse guys.

This is coming up for us and just wondered if anyone out there has already done this and has any pointers, gotchas, tips, tricks or anything else to contribute to our happiness.

I understand that SVN 1.5 is a fairly major release which incorporates new merging facilities.

We will also need to update the eclipse plugin 'subclipse' that we use to a compatible version. I have started looking at the version we need but think just the latest (1.4.5) will work best. Currently we are using 1.2.4 because we are pointing to our pre 1.5 repository.

If you are working on a file in your project in eclipse and for some reason you need to change the contents of that file to be the contents of the same file but a different revision within the repository, then you would think that the Replace with, Branch/Tag or Revision would do what you need.

I find however that the implementation of this function is not quite as expected (and not the same as when using the same function under CVS).

I would expect that the contents of the current revision are replaced with those of the selected revision (just as though you have made these changes by manual editing) and that as a result this file now needs to be committed.

Now this is exactly what happens if you choose the Revison option - that is a revision in the same branch. You are shown a list of revisions and if you right click you can 'Get revision' or 'Get contents' - Get contents replaces your current files contents withe the selected revision contents and leaves your local copy in need of a commit.

If you select a revision from another Branch/Tag then a 'switch' command is run and your local copy is switched to that branch. You will notice that the SVN icon changes to blue. If you team, update this project, your file switches back to the one on your own branch.

Does anyone else think this behavior is incorrect?

As I've blogged here before, there are two SVN plugins available for eclipse, subclipse or subversive. We started using subclipse because on balance it seemed to have most supporters. So we used that for a few weeks.
I should explain that we use branches extensively in the development process we use and so we also have to merge these branches back to the trunk. The merging facility of our chosen plugin becomes perhaps one of the most vital parts since this is the trickiest operation and you need all the help you can get!
Using CVS (as we did before SVN) the CVS process within eclipse (I won't say plugin because it is part of the core eclipse build) creates a tag of root_branchname when you create the branch and then when you come to merge defaults to merging from that tag to the current HEAD revision. In the currently, SVN requires you to identify the revision number prior to the root of the branch as the source of the merge. This is more fiddly than I would like, with no defaults and every chance of an inexperienced developer getting something wrong.
Finding the source revision was not always straight forward on some machines we had to use tortoisesvn to look this up as subclipse seemed to be unable to list it correctly. Not only do you have to select the source revision in the branch but also the target revision in the trunk. The target revision is 99.9% going to be the HEAD revision of the TRUNK but this is not the default so you have to remember to set that as well. The merge is always carried out, even when there is a conflict. In CVS you had the chance to review and edit conflicts prior to the merge being done.
These issues made me take a second look at subversive. To start with it seemed a better plugin. You can always find the source revision although in principle the same issues of having to get this right remain. When you merge the merge is not carried out rather you get to review each change and copy these over one by one and then mark each merged file using 'mark as merged'. For small merges this works well, but for larger ones or for branches that have lived longer (time apart from the trunk) there may be a lot of changes in any given file - some have happened on the branch and some on the trunk. Here a major subversive flaw appears - the conflict editor view does not distinguish which changes have happened on the branch and which are from the trunk. This is vital to a complex merge, since you want to focus on the branch changes and be able to assume that changes already on the trunk are good (reviewed by someone else). Subversive also had some 'features' related to how you merged folder trees you had to select the folders beneath the top folder rather than the the top folder else it took a very long time to merge. These issues finally drove me back to subclipse. I'm more used to the selection of revision numbers now and my clean install always seems to be able to list the revisions clearly. Best of all the conflict editor clearly colours the changes black for changes on the trunk, blue for branch changes and red for branch changes that conflict.
The next release of SVN promises better merge control from the repository so these issues may all vanish.

We have been using SVN for the last few months, now having been CVS users for about 3 years before that. While SVN is a sensible choice for the future, we are finding a few weaknesses in the current implementation and I will be posting details of these over the next few days.
The first issue is that running apache webdav on windows server 2003 we find that it slowly consumes more and more memory until it runs very slowly and eventually stops other processes running correctly.
We have reduced the thread limit in the hope that it will force apache to create a new process once this limit is reached but it does not seem to do that.
We continue the search for a good solution to this...