Paul Lorenz <plorenz@gmail.com> wrote on 01/27/2006 11:44:23 AM:
> Trying to learn the subclipse way of doing merges. I have three
> problems so far, and a fix for one of them.
>
> The first is when you are actually doing Edit Conflicts using the
> built in editor, the diff state isn't recalculated after doing a save.
> Also, the copy current change stops working after the save. I fixed
> this, usually a similar method that the CVS plugin uses, by having a
> subclass of DiffNode which we have the differencer use, and then
> calling fireChanges on that in the save. Patch is attached.
>
> Please let me know if the patch looks acceptable, or if it needs work,
> or if it's working as expected, and I'm just missing something.
I will take a look when I get a chance. I am not entirely sure as to the
problem it solves, so I may need to spend some time producing the problem
first.
> The second is that after doing a merge, the only way I can see to
> find the files with conflicts is to look in the SVN Console. It would
> be nice if these showed up in the Conflicts view in the synchronize
> view. I'll take a look at this, though it may be more difficult :)
We create Problem Markers for all files with conflicts. So they should
show up in the Problems view. You might need to bring up the Filters
option and be sure that the SVN Conflicts problems are showing. We then
provide several options on Quick Fix to deal with the problem.
> The last thing is when reverting a merge, I'm still running into
> problems. I get an error that a given file isn't under version
> control.
>
> revert -N
/home/paul/workspace/foo-dev-svn/lib-dev/resin-3.0.14/.cvsignore
> svn:
'/home/paul/workspace/foo-dev-svn/lib-dev/resin-3.0.14/.cvsignore'
> is not under version control
Is it possible you are reverting the folder that contains this file at the
same time? I have seen situations where it reverts the folder first
(which reverts the files) and then tries to revert the file. In order to
revert a file it has to either be versioned in your repository, or be a
schedule add. In the case, of the latter, it goes from being a scheduled
add to an unversioned file, not a deleted file.
> This kills the revert. Is it because the file is called .cvsignore?
There is a small possibility that if the file is in the Eclipse Ignored
resources list then that is contributing to odd behavior.
> I retry the revert, I get the same error, but on a different file (not
> a .cvsignore file). I would think revert should either ignore or
> delete file that aren't in repository.
If my original guess is true, that the folder was reverted, then the
second time you run it the file is likely already reverted and therefore
it is not attempted again.
> Even if that error is fixed, it's still a pain to use revert. What
> happens is that I'm left with a bunch of additions. I then delete
> everything in my synchronize view. However this includes a bunch of
> folders which have files in them other than the added ones. So then I
> have to revert that set of deletions. So I have to revert, delete,
> revert to clear out the merge.
It is hard to know the exact scenario you are describing, but you ought to
be able to Revert an entire project in one swoop. The only issue is that
files that are new, and thus in the Added state, will not be deleted by a
revert. They will simply be "un-added".
> I saw there is an override and update
> option. However it is only configured to work in the Conflicts view.
Override and update would only apply when there is a Synchronize conflict.
It basically means you have a local change and the file is also changed
in the repository. It does a revert of the local change, followed by an
update from the repository.
> patched it to show up for outgoing, but it didn't delete my added
> files either. Suggestions? Can I patch override and update to do the
> added file deletion? Or add a different option which does the same
> thing?
Personally, I would rather not differ from Subversion in this area.
Subversion does not think that a revert should delete the local file, for
safety reasons. I also do not think that adding a bunch of new options is
a good idea from a usability point of view. If we were going to do
something, I would think it would be to patch the Revert dialog and
process to expose an option when added files are present that indicates
whether they should be deleted from the filesystem. You would have to do
the delete as a post-step to the revert process.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Fri Jan 27 18:40:36 2006