On 4/27/2011 12:20 AM, Jonatan Soto wrote:
> Sorry if we were mistaken, but when the merge finishes (following
> Ryan's indications) it says:
> Summary of conflicts: Text conflicts: 15 Tree conflicts: 8
> Perhaps the problem is that we are using the latest subclipse plugin
> as a client and if we are not wrong it is based on 1.6 client.
Ah, yes, that'd be it. So in that case you (the user) are actually using
1.6, not 1.3, and you should be able to use the --reintegrate option
> We've downloaded a 1.4 client but when we use it, says that the
> version is not correct. We assume that it is caused because the
> working copy was previously checked out using subclipse. The
> subversion server is 1.3 for sure, it is shown at the bottom of the
> page when we are browsing it through a web browser.
Yeah, generally speaking all of your subversion-based client-side tools
need to be built using the same version of subversion, or else you run
into problems like this. I don't use subclipse myself, but there should
be a way to find out the exact svn version it's built from.
> On the other hand, I totally agree with you, we should upgrade the
> svn server version but we are working for a big company and as you
> can figure it out, the infra team would not be agree with us if we
> tell them to upgrade. Many projects are under this repository and it
> won't be easier to tell them that (lot's of bureaucracy).
Out of curiosity, have you actually asked? Subversion is designed with
the idea that any 1.x client should be able to work with any 1.x server
(as you've demonstrated by using a 1.6 client against a 1.3 server). The
infra team should be able to upgrade to the latest 1.6 server and none
of the project teams need to care. It doesn't really matter for the
problem at hand, but there are a lot of performance benefits that might
make the infra team happy, like reduced storage space on the server.
Received on 2011-04-27 19:38:04 CEST