[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Help me convince admin to upgrade TortoiseSVN!

From: Simon Large <simon.tortoisesvn_at_googlemail.com>
Date: Mon, 30 Mar 2009 16:43:32 +0100

2009/3/30 Phil C <chublogga_at_gmail.com>:
> Our standard desktop build comes with Tortoise SVN 1.4, and I belive our subversion servers are running subversion 1.4.x as well.
> Until recently, our admins didn't care if we upgraded to the latest version, so we had some using Tortoise 1.4.x, some on 1.5.x.   Recently there was a commit issue where developer A (using 1.5.x) was committing changes on an older revision (say rev 10), and developer B's (using 1.4.x) changes (done in rev 12) were being overwritten.   The admins and developers in question are attributing this "bug" to the fact of having different tortoise clients on their machines.

No, absolutely not. You *cannot* commit files which are not updated to
HEAD; that's a fundamental design feature of subversion.

As to exactly what happened, I could not say. First of all I assume
you are using a proper svnserve or apache server (svn:// or http://)
and not file:// access, and that you are not using shared working
copies. If you do either of those things then you are going to get
into trouble.

One possible scenario is this: Developer A makes changes based on r10
but doesn't save them. A then updates to HEAD (r12) in explorer and
then saves then changes in the editor, overwriting r12. Some editors
will notice that a change has been made externally and offer a choice
of keeping the external change (discard own changes), or keeping your
own changes (discard external changes). Clearly this is a no-win
situation and the moral is never update your working copy while there
are unsaved changes in your editor. No VCS can handle that cleanly.
Similar issues arise if A has an editor which doesn't notice when the
file is changed by another program. A saves the file before updating,
but after the update A makes one more small change and re-saves. If
the editor fails to reload the merged file, again the r12 changes are

> Now, i'm not trying to pull a CSI here and figure out what went wrong - we managed to correctly merge all the changes together.   I'm of the mind that there was something else at play here besides just having differing clients, and without having seen the problem firsthand, it's going to be impossible for me to figure that out.
> BUT now our admins are telling us all to revert back to Tortoise 1.4.x in order to prevent any more of these "conflicts".
> First of all, can somebody confirm to me that there is no issues with different developers using different version clients (1.4.x and 1.5.x) with an older subversion server (1.4.x)?

Any 1.x client will work with any 1.x server, with the exception that
new features which require a minimum version of client and server may
not be fully supported. The subversion website shows the compatibility
guarantees. You cannot use different revision clients on the same
working copy as they get auto-upgraded to the later version which the
earlier client will not then understand. Nor can you use different OS
clients on the same WC, e.g. Windows clients and cygwin client.

> Secondly, what could I tell my admins in order for them to allow us to upgrade to the latest version, 1.6.0?

Personally I would wait for 1.6.1 as there have been a few teething
troubles with 1.6.0, and your admins will be saying "told you so,
never upgrade again". But once those are fixed there are some very
nice features added since 1.4



:       ___
:  oo  // \\      "De Chelonian Mobile"
: (_,\/ \_/ \     TortoiseSVN
:   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
:   /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-03-30 17:43:56 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.