For starters, I'm going to get myself acquainted with the project.
I'll peruse this list and the issue list when I'm ready to code. I'll
keep you updated.
-M
On 8/5/05, Mark Phippard <MarkP@softlanding.com> wrote:
> Mike DeHaan <mikedehaan@gmail.com> 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
> enough.
>
> 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
> folder.
>
> 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.
>
> Mark
>
>
>
>
>
>
> _____________________________________________________________________________
> Scanned for SoftLanding Systems, Inc. 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 Sat Aug 6 11:26:39 2005