Panagiotis Korros <panagiotis.korros@gmail.com> wrote on 11/07/2004
02:49:15 PM:
> Some comments on this discussion
>
> 1. Conflict Editor
> Eclipse already has a compare/conflict editor. The editor we use to
> compare with BASE or remote can be made to work as a three way editor
> (like the cvs plugin) comparing local with remote using a common
> ancestor (BASE).
This could be used in the synch view, but if I just do an update and a
conflict is created in my working copy, could it be used then? I still
like the idea of adding a preference to launch an external program. As I
said, there could be a default of "built-in" once we have a way to do this
within Eclipse.
> 2. Merge
> We could port the merge synchronizer/participant from the CVS plugin
> and use svn merge -dry-run to populate the synchronizer. This would
> show a list of resources that need updating and will also show the
> conflicts.
That sounds good.
> 3. Update to Revision is in fact a 'Replace with revision' action in
> eclipse terms. I think we should keep the eclipse terminology.
First off, I checked before I wrote this, and did not see that option
available in my Subclipse projects. So I assume you are just suggesting
that is the way to implement this? Second, I am not sure I agree,
although I have never used this option in Tortoise. I assume this option
exists for a specific scenario. Say you are at revision 1000 in your WC
and have made a bunch of changes. You know that the HEAD revision (1050)
has some conflicting updates, but you need some non-conflicting updates
made by someone else in revision (1044). This option would let you bring
your WC to 1044. I just think Replace with seems unintuitivein this
scenario.
I wonder if Replace with might not be the way to approach the "Switch"
option however?
> 4. We could use the ecliplse 3.0 cvs images to make the subclipse
> icons to be consistent with the eclipse ui.
Fine with me. I am not using CVS anymore, last time I did, it did not use
many images. I personally, like having images on menu actions, but it is
not critical to me.
> 5. Subclipse currently is a mixture of eclipse 2.1 and Eclipse 3.0 CVS
> code. We should try to use the eclipse 3.0 api more.
> In particular the jobs api is a powerful tool to execute commands
> (operations) in the background by locking only the affected resources.
> A start has been made with the update action that uses the
> TeamOparation API. It locks the project that is being updated and
> allows the user to work on other projects.
> All lengthy subclipse actions should be backgroundable.
I think this would be great to have, but in my opinion, it is less
important than getting all the functionality nailed down. That being
said, this is open source and if this is an itch you want to scratch I do
not have any objections. I just think that Subclipse has been stagnating
a bit while working on these newer features. I think my document showed
that there are only a small number of core features that are missing. It
seems worthwhile to try to nail these down and then start making things
"better".
I would also like to see some of these core features backport to Eclipse
2.1 as the IBM WSAD base is not insignificant.
> 6. The sync view is a powerful tool. We use the svn status -u command
> to populate a tree with local and and a tree with remote changes.
>
> Implementing it for subclipse has many problems because the javahl
> bindings doesn't give anough information to populate it correctly.
>
> Problems:
> a. We don't know if a remotely added resource is a file or directory.
> b. We don't know the revision that a remote resource was changed.
Can't these things in JavaHL be fixed?
> Currently it not used because it is not complete. things to be done:
> 1. Add Commit, Update, Ignore, Add to version control
> actions to the sync view (these actions must implement the
> SynchronizeModelAction).
> 2. The sync view should be made to listen to the
> workspace modifications and update itself automatically (partially
> implemented and buggy).
> 3. Write unit tests
>
> I am working in the sync view but currently i lack the time to make it
> work. Any help would be appreciated.
How about you take ownership of the "Synchronize feature" and define the
work that needs to be done? Break it up into chunks and ask for
volunteers? For example, it seems like there are a number of people that
could probably tackle the actions, while you perhaps work on the core
synch parts? Just a thought. I think a lot of people know you are
working on this, and do not want to step on what you are doing. More
communucations might help move it along.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Tue Nov 9 01:18:27 2004