Eugene Kuleshov <eu@javatx.com> wrote on 08/16/2005 10:30:06 PM:
> 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? First off, I am not against this
feature. I think I have been clear about that. 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.
> 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.
> 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?
Submit a patch, that is the best vote. You seem to be under the
impression that I am against this feature. 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.
> 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.
> I think above is bullet proof enough. Am I wrong?
You just provided a code snippet. On what basis is it to be judged? 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? 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.
Once it is in svnClientAdapter it should just be a matter of changing the
UI to allow this again.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Aug 18 03:44:00 2005