Eugene Kuleshov <eu@javatx.com> wrote on 08/17/2005 02:52:13 PM:
> Mark Phippard wrote:
>
> I just got an impression that it is not the first time when isses had
> been rejected with Closed/Wontfix reason and comment "There is no
> support for X in Subversion or Subversion Client". It would be more fare
> to recognise the issue and leave it open (ore resolve later).
I do not think our issue tracker is the place for requests that are not
supported by Subversion. If someone wants to store their repository in a
SQL backend should we have an issue for it? If someone wants a working
copy with no pristine copies should we have an issue for it? I just want
the issue tracker to be usable for people looking for something to do.
When Subversion adds new feature we typically add support for them
quickly, if we do not, then that is the time to open an issue. If you do
not like it, then simply participate more. Put in 1/10th the time that I
do. I am not (intentionally) preventing anyone from bringing different
values to this project.
> Right. We have Subversion on one side of the fence and Java IDE with
> over 3 years of history. Both tools has their own "best ways". But I
> truly believe that tool integrated into IDE should at least try to match
> existing user experience (there are other tools that already provide
> just Subversion experience). I know we have disagreement on this point.
:-)
We do have some disagreement in this area. I do not believe that Eclipse
has a defined standard in this area. I believe the intention was always
for tools to do what is best for that tool. In addition to the CVS
client, I have used the PVCS Version Manager and ClearCase client amd I
have demoed several others. I would say that the only thing that most of
them have in common is putting stuff on the Team menu. Which is one of
the few things that Eclipse specifically encourages. I want our UI to
feel like the CVS client as much as possible. Where we differ is that I
think there are a lot of core areas where Subversion and CVS are
sufficiently different that this does not make sense.
> > Submit a patch, that is the best vote. You seem to be under the
> > impression that I am against this feature.
>
> I know that you just not willing to. To me it is the same as
> "against". :-)
Against would mean that I would veto applying a patch. That is not the
case. I am just not willing to do the work myself. Really it is more
that I am not able. The work required for this does not fit with my
background and skills. I think someone else could do it better. I also
do not think this is worth doing at all if Subversion 1.3 will include the
feature that is needed.
> Mark, please don't get me wrong. It doesn't really matter how UI
> behaves and why did it happens when it is preventing user to get what he
> is looking for. The important thing is to get the feature in for
> everybody use, because it is sooo common use case.
So you think it is better for someone to get a NPE and just assume this is
a bug in our Synchronize code? I just do not agree. I do not think the
use case is all that common and for the majority of people the workaround
is not that hard. Just to manually do what you want to do programatically
is absolutely trivial. Again, I think Subversion, and therefore
Subclipse, ought to support this, but I hardly think it is earth shaking.
It is far worse that before I made this change we were giving the
impression that we were going to support it and that you just ran into
some bug.
> It is also unclear if it is just JavaHL client or there are changes
> on server side, which will slow down the adoption.
This is a general Subversion client library issue, not specifically
JavaHL. JavaHL is just a thin wrapper to the Subversion client API. To
do the version that only downloads modified files might require a server
or protocol change. The crude version could be done right now. JavaSVN
could probably do it.
> >> I think above is bullet proof enough. Am I wrong?
> > You just provided a code snippet. On what basis is it to be judged?
>
> Well, it is an Ant code which runs on thousands of environments for
> years. To me it is sounds like safe to use.
My point was that your snippet only addressed a small piece of what needs
to be done, as you acknowledge at the end of this message.
> Can you please put some stubs/interfaces for these operations? Then
> it would be easier to me to put a patch together...
>
> > Once it is in svnClientAdapter it should just be a matter of changing
the
> > UI to allow this again.
>
> There is an user interaction required as I described in my previous
> email. How is that handled in adapter? E.g.:
>
> -- Select Project and temp foldes
> -- Ideally - show progress on checkout, on copy, delete and compare.
> -- Report list of changed files and request user to choose an action:
> ignore, overwrite + synchronize, something else (?). In the same dialog
> it should have checkbox "Delete tempDir on success".
I still think you should wait until we know if Subversion is going to
address it. If you want to tackle it, and have me do something, then come
up with a more specific design. I would ideally like to see this done
without any new UI, the same way Subversion would do it. What you
describe sounds confusing and complicated for the user.
At a high-level, what I think needs to be done is this:
1) Move existing project to TEMP
2) Checkout project
3) Copy existing project on top of checked out project (this might mean
copying files individually)
4) Run svn cleanup to fix the stored timestamps for files that are
unchanged
You probably have to do some of this without Eclipse knowing about it.
I do not think you need to do compares or any of that stuff. The user can
always use revert to undo changes they did not want. Of course they can
also do a compare to see what they changed. Likewise, commit will just
pick up the real changes itself and the existing wizard will already
launch the commit dialog at the end.
My concerns are still the edge cases:
1) Line endings might not be correct
2) keywords might not be expanded correctly. Would this cause incorrect
diffs?
3) svn:needs-lock and read-only attribute might not be correct
Personally, I think that documenting the manual steps, making the UI
reflect what we are able to do, and modify when Subversion can do this, is
the better approach. You are free to work on this, and I will help you as
best I can.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Aug 18 05:32:28 2005