Are you using Subclipse or Subversion as your Eclipse SVN client?
I used to have a ton of trouble when using Subclipse and could never keep my source in sync.
All fixed once I started using Subversion. Subversion also does synchronizing merges like the old CVS plugin so you get to see what is being merged in and can play with it by hand. Nothing gets merged in without you seeing it. I find this gives me far greater control.
The Start revision number should be the revision number that you last merged your branch up to. Whenever I commit a merge, I always add a comment ‘Merged up to trunk@1234’ to remind me what that revision was. Then you can see it easily in a ‘Show Resource History’. I have enver trusted the ‘Auto’ setting.
Remember what a merge is doing - When you specify a start (and possibly end) revision number, these revision numbers refer to the trunk, they have nothing to do with the source. The trunk is compared from start revsion to end (or latest if no end specified) and then any changes found in the trunk between the two revisions are applied to your branch source.
Isn’t Subclipse the Eclipse plugin for Subversion?
The trouble may be because I don’t remember what the last revision I
merged from was. The second problem is that if you have a conflict
then it refuses to merge even if you resolve in favour of the archived
What I’ve done now is reverted to the archive. However, what that
really means is I’ve reverted to the mkiefte branch which is not what
I wanted to do. On the upside, I can give it a correct revision
number from which to merge from the main trunk because I committed to
the mkiefte branch right after the last merge (which went fine
apparently). But then there are still conflicts. Then I try to
resolve the conflicts in favour of the archive and I’m currently stuck
in an infinite loop… Aargh!
This is why after every merge from the trunk to one of my branches, I ALWAYS do a commit immediately with the comment ‘Merged from trunk@2641’ or whatever the current trunk version is. Makes life so much simpler.
This is where Subversive is vastly superior. When you merge and there are conflicts, it opens both copies of the source side-by-side in a synchronize windown and highlights the matching parts in both sets that are different. You then get to manually merge your conflicts and save the new version.
Try Subversive and let us know how that goes. You may need to create a fresh branch and merge in your changes from your current branch. In this case, you choose to merge from the old branch, not the trunk and use a start and end version number that encompasses the changes you committed to your old branch.
I’m thinking that this would not actually be that hard to implement.
We add a an extra Zoom factor to the zoomer which is how much to zoom counters relative to the map. If we want to reduce the counters by a third when displayed on a full size map, then the factor would be 0.667. The new Zoomer will allow you to Zoom the Map to 150% which would then show the counters at full size.
The Zoom level for counters is pretty much passed directly to the draw() routine, so a few changes to Map should sort this out.
I’m thinking a fixed relationship between the Map Zoom and the Counter zoom, but there is no reason why you couldn’t zoom both independently. Just the complexity of the controls becomes an issue. A fixed relationship (defaulting to 1.0) would be most compatible.
I would add a little so that if the Counter zoom ends up within (say) 5% of 1.0, then set it to 1.0. This would take of rounding errors and ending up with counters zoomed to 99.3% size.