Mike DeHaan <firstname.lastname@example.org> wrote on 08/05/2005 07:53:04 PM:
> As I think more about this, I would like to help. I want to own this
> enhancement. Since it's not critical to your 1.0 release, I think it
> would be a good place for me to start.
> How do I become a contributor?
Just checkout the core and ui projects from trunk and submit a patch.
I would not recommend you start with this feature. The Synch code is very
hard, and the current API for dry-run isn't well suited for what you want
to do. I suspect we would have to get Subversion to make some changes to
the JavaHL API if we were to do it. The only info we get from merge,
including dry run, are "notifications". which are what you see if you show
the console. It would be possible to intercept all of those strings, but
that is all you would get for information. I do not think it would be
After your previous message I was thinking about this some more. The one
feature that we really need we have an open request into Eclipse for. And
that is to be able to pass the Eclipse compare engine a local resource(s)
and a unified diff and have it build the compare UI from that. Which it
should be able to. Currently, you have to feed Eclipse the two sets of
info and let it do the compare. There is a lot of really cool stuff we
could accomplish if Eclipse has this feature. This is not an area where I
have the necessary skills, but if someone else wanted to tackle it ...
The areas I would love to see someone commit some work right now are in
the areas where users first rub against the product -- checking out and
sharing. For Checkout, there have been a lot of requests for features
that CVS has. Personally, I do not think we could do most of them because
the Subversion working copy rules will get in the way. I do think we
could make the Checkout As... process work better. Currently, to be safe,
we have to "scrub" the location where the checkout is going because the
Subversion checkout will abort if it runs into a file or folder that is
also being checked out. We could handle this better such as:
a) Showing the user the list of items we will delete, with an option to
not delete certain files.
or better would be
b) For each file, try to figure out if it exists in the repository and
only delete those files
or perhaps best would be
c) move the files/folders to a safe location, do the checkout and then
copy the files back. If files existed in the repository, it would just
show as a local modification
For Sharing a project there are several things.
1) I think the dialogs were copied from CVS and they share the terms of
CVS. For example, Subversion does not have modules, so we shouldn't use
those words on the dialog.
2) If someone wants to check-in to a ProjectName/trunk structure we will
fail if ProjectName does not exist. We should just do multiple mkdir's to
create the structure. The UI could also be improved in this dialog.
3) Currently, at the end of the Share process it launches Synchronize. I
think this is another CVS copy. New users always seem lost by this. I
would recommend not doing the Synchronize and instead programmtically
bring up the commit dialog as if they specified that option on the project
4) We should not allow the user to specify a directory name that already
exists. Currently, the process pretends that it is going to allow this
and just Synchronize with the repository but this would be virtually
impossible to implement with Subversion because you have to have a working
copy locally to do this and you do not have one.
5) When someone disconnects a project we need to make it really, really
clear that if they delete the .svn folders they will not be getting this
project back under Subversion control. This is related to #3.
Thanks. I hope this gives you OR ANYONE ELSE, some ideas.
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
Received on Sat Aug 6 10:44:59 2005