> 1. When doing Checkout... from SVN repository view, if you leave the
> default project name, it isn't used.
I will see if I can recreate. Are you sure you had the right radio-button
selected? If there is a .project file in the selected folder it reads the
name from that file for the default, otherwise it uses the folder name.
> 2. This isn't so much a bug as a feature request. When using the CVS
> plug-in, you can "Preview the merge in the synchronize view". This is
> extremely useful. It allows you to find conflicts and resolve them using
> the eclipse diff engine, which is much better than digging for >>>>
> <<<<<<. It also lets you see exactly which files have changed. Is there
> any chance this will be implemented?
There is always a chance, but I am not aware of anyone working on it. I
might just lack imagination, but I do not see how it could be implemented
without writing our own merge and ignoring what Subversion provides. I
have never looked at what the CVS plugin does or if it has to deal with any
of the issues we would. I think it would be a bad idea in the long term to
deviate from the Subversion merge process. The devs are in the process of
designing the next wave of features for this process, including merge
tracking, and I would think you would have to use their process for it to
pick up those features.
Anyway, feel free to look at what the CVS code is doing and see if you can
implement something similar. We do not have a lot of API available to us
in this area, but you could likely get a unified diff of the text
differences and possibly build something from that. I am not sure how you
would merge binaries or SVN properties etc...
> 3. After doing a merge into my workspace, I tried to revert the merge,
> but it didn't work. Whenever I clicked on revert, it would process for a
> while, but not do anything.
Did you do this from the Team menu or the Synch view? Did you see if
there were any errors in the error log.
> In general, it seems like files which have been added to the workspace,
> but aren't in subversion cause problems.
This is pretty common and should not present a problem. One small gotcha
is that if you do a merge and then do a revert, the revert will not remove
any files that were added by the merge. It will only undo the
scheduled-add but will leave the file in the workspace in an unversioned
status. Subversion does this to be safe.
> #2 is really a killer for us, as we do a lot of merging, often every
> week, between QA/DEV/HEAD branches, so anything that helps us keep our
> merges clean is very hard to give up.
Maybe it is just the background I came from, but I never really get why
someone would want to do this graphically. I would rather fire off a merge
and let Subversion do all the work. If there are any conflicts I have a
nice graphical editor to resolve them. That just seems easier to me. If I
am not ready to do the merge, but I want to get an idea what is going to
happen I will use the Dry Run option to see if there are any conflicts. I
also have the Unified Diff option if I want to inspect the incoming
changes. I am not saying there is not a place for the graphical view, I
just do not see why it is such a show stopper.
Anyway, I am sure someone will try to implement this in some manner some
day. It probably will not be me though.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Wed Jan 25 02:12:00 2006