Mark Phippard wrote:
>> No offense, but I believe you are trying too put too much of the
> Subclipse
>>concepts into Eclipse IDE. It doesn't seem match to what users would
> expect.
> I assume you mean Subversion concepts?
You right, sorry. I is Subversion of course.
> First off, I am not against this feature.
> I think I have been clear about that.
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).
> Second, I do not think
> this is a matter of conflicting "concepts". It is simply that the current
> implementation of the Subversion libraries do not provide the API's we
> need to do this. In this case, I think it is more of an oversight in
> Subversion than anything else.
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. :-)
>>Also, I doubt that many users would complain about implementation that
> is
>>actually work and will give credit to the workaround-free implementation
> that
>>does not work. Personally I don't really care how feature is actually
>>implemented as long as it work.
>
> The key is that last statement, "as long as it works". My concern would
> be the edge cases, In this case the original poster also specifically
> seemed to want to avoid the checkout process due to the size of their
> source tree. To be fair, that may be an unsolvable problem. Even if
> Subversion adds this feature, they might still do a full checkout. That
> is the main area of debate right now.
Maybe you are right. However I've interpreted his comment is that
checking out again would be too many manual operations. After all it
will take no longer then it has to (disk space could be an issue),
especially if there is no other way at the moment.
>> As an experiment we can try to collect some votes for this issue and
> see if
>>users would actually prefer to get slow and simulated version then wait
> when
>>it will be implemented in Subversion. Personally I've been waiting for
> this
>>over 8 months if not a year.
>> So here is my +1 to have slow simulation.
>
> What is the point of having a vote if no one is willing to do the work?
It has very little todo with williness actually. If nobody will shout
for this, there will be no attention to the importance of this feature
and it will be never implemented.
Developer's opinion can be biased and sometimes it is really
necessary to bring the attention to the popularity of the issue and
study actual usage patterns.
> 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". :-)
> I am not at all. It isn't
> like someone wrote this feature and it just had bugs. Someone copied the
> CVS code which launches Synchronize at the end. This was done before we
> even had a Synchronize, whomever wrote it probably assumed it would just
> work when we did. It doesn't. Until there was a way to make this
> actually work the only correct thing to do was stop it in the UI.
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.
>>Your summary of conversation with svn developers
>>doesn't really sound optimistic.
>
> I must have worded my sentence poorly then. The Subversion developers
> agreed that the checkout command ought to work the way that we need/want
> it to. Some even thought it ought to be the default (despite the behavior
> change). The only question was whether to go "all the way" and try to
> avoid downloading files that do not need to be downloaded. In short, this
> is all very optimistic.
It is also unclear if it is just JavaHL client or there are changes
on server side, which will slow down the adoption.
>> 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.
> I do not think we would accept adding ant as a runtime requirement.
> This code
> would have to go into svnClientAdapter and I do not think we would want to
> add that as one of the dependencies. svnClientAdapter has the same
> license as Ant so perhaps the code could just be copied?
Fair enough. Of course Ant's code can be copied. The license doesn't
prohibit this (well, you may have to credit Jakarta somewhere though).
> Personally, I
> think that the existing checkout methods in svnClientAdapter ought to just
> support this. I would suggest adding helper methods on
> AbstractClientAdapter that handle the details of moving out and moving
> back in. I would then add code in the existing checkout implementations
> to call those methods. There probably ought to be a boolean method that
> indicates whether the checkout implementation already does this itself.
> That way, if JavaSVN added this in to their core features, you could skip
> the extra coding. Look at what we did with the status command as an
> example.
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".
Does this make sense?
regards,
Eugene
Received on Thu Aug 18 04:52:13 2005