> -----Original Message-----
> From: Phil C [mailto:chublogga_at_gmail.com]
> Sent: Monday, March 30, 2009 7:35 AM
> To: users_at_tortoisesvn.tigris.org
> Subject: Help me convince admin to upgrade TortoiseSVN!
> Our standard desktop build comes with Tortoise SVN 1.4, and I belive
> 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.
> there was a commit issue where developer A (using 1.5.x) was
> changes on an older revision (say rev 10), and developer B's (using
> changes (done in rev 12) were being overwritten. The admins and
> developers in question are attributing this "bug" to the fact of
> different tortoise clients on their machines.
> Now, i'm not trying to pull a CSI here and figure out what went wrong
> managed to correctly merge all the changes together. I'm of the mind
> that there was something else at play here besides just having
> clients, and without having seen the problem firsthand, it's going to
> impossible for me to figure that out.
Subversion doesn't make it easy to just wipe out someone else's changes,
but it certainly is possible and doesn't require different client
versions to happen. If a user updates their WC and then just dumps
their "branch" copies over top of their WC, then this can happen,
because they're basically merging outside Subversion. A similar thing
happens if they just use an external 2-way merge tool instead of using
Subversion to merge the changes. Another thing I've seen is that
Subversion's merge can silently fail to merge a revision--in my case,
the file came into conflict from one merged revision, and the next
revision simply didn't get merged over, even though it was marked as
having been merged. But this problem is present at least in 1.5.x and
probably in 1.6.x as well.
Rather than blaming Svn, in most cases I would point to user error
because users ultimately decide what they commit. Did they check the
commit window's change listing and look at the diffs before committing
(actually reviewing their own code)? I recently had a coworker
wondering why some files mysteriously vanished. I looked through the
log and saw that he had deleted them. He said that Subversion gave him
"no indication" of this. I had to disagree; I've never seen Subversion
commit anything different from what it said it would.
> BUT now our admins are telling us all to revert back to Tortoise 1.4.x
> 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)?
The main issues I would think you could expect would be related to the
lack of mergeinfo in 1.4.x. 1.5.x may expect this to be used--I say
"may" because I'm not sure how true this is with a 1.4.x server.
> Secondly, what could I tell my admins in order for them to allow us to
> upgrade to the latest version, 1.6.0?
I hope this doesn't sound too harsh to the TSVN team, who have done a
lot of work to produce 1.6, but my personal opinion is that 1.6.0 is bit
buggy to use. It looks like the nightly builds have fixed several
serious issues, so I'm very hopeful for a stable 1.6.1 TSVN (though I
would prefer they released sooner than later, because I don't think I
can validate a nightly build for my company's use).
You can have a look at the changelog at
http://nightlybuilds.tortoisesvn.net/1.6.x/changelog.html and decide for
yourself. In particular I'm noting these types of fixes:
- fixes to blame not working
- fixes to revision graph crashes
- pointer-related fixes
- memory leak fixes
This may prompt you to ask whether you should stick with some particular
1.5.x variant. If you do, I suggest checking all the release notes to
decide which one looks best to you. 1.5.8 looked good to me, though on
my machine it crashes every time I try to merge (and this is
mysteriously fixed in the 1.6.x code, possibly due to changes in the Svn
internal libraries) so I have to use the command-line client to merge.
Note that early 1.5.x versions on the other hand use older Svn libraries
which are not as good with merging.
Bottom line: Software isn't perfect, so choose carefully what defects
you're willing to live with, and run validation tests to make sure the
software is suitable to your organization.
BTW, the aforementioned changelog seems to have a bug where it stripped
off the first 2 characters of "branches" so you see "anches" throughout
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-03-30 17:23:39 CEST