Experiences with Subversion & TortoiseSVN?

[MergeThis]

We're investigating switching from RoboSource Control to Subversion & TortoiseSVN. Although a free, easy-to-use product, it appears to be quite flexible and forgiving, especially when dealing with file renaming/deleting and reconciling changes between branches.

Has anyone using Subversion run into particularly nasty gotcha's, or bothersome quirks not covered in their help (which is quite good, actually). This would be used for a 42-project merged system, branched for at least three concurrent software versions.

Thx,

Leon

[RoboColum_n_]

Hi Leon.

We use SVN and it works pretty well for us. One thing to watch out for is where you have multiple authors working on the same documentation project and therefore potentially sharing source files. With SVN you can checkout the source regardless of whether another author has previously checked it out. It is only when you checkin that you may find conflicts (e.g. if two people have checked out and someone else has checked in before you). To get around this we always check out the entire RH project and use the SVN Lock command on the project's XPJ file. This means the author has to check in the RepoBrowser before checking out to see if someone else has the project locked. If they haven't, they checkout. The beauty of this is that when you checkin it automatically reoves the lock.

One other minor issue for some, although not for us, is the presence of the .svn folders. If you search for this is this forum you'll find a post by Ben Minson that highlights the issue.

---

The RoboColum(n)

@robocolumn

Colum McAndrew

[ianwild]

One other minor issue for some, although not for us, is the presence of the .svn folders. If you search for this is this forum you'll find a post by Ben Minson that highlights the issue.

You'll be pleased to know that in the next release of Subversion (1.7 Release notes), one new feature (among many) will be centralized metadata storage. This means working copies will have just one .svn directory in the root of the working copy rather than one in every folder. This should remove the issues Ben highlighted.

SVNs strength is it's very active communities and numerous places you can go for help. It's a very mature tool used widely by all sizes of development shops and organisations that need versioning for one reason or another. Some of the SVN deployments we support have tens of thousands of users and although there are always things here and there that any software package could do better, all round I think you'll find Subversion meets more needs than anything else available - open source or otherwise.

Best Wishes,

Ian Wild

WANdisco Inc

[MergeThis]

Thanks, Colum & Ian.

It all looks good. My manager is already running full-blown tests, and we're all looking forward to disconnecting from RSC 3.1.

In case anyone's wondering why, we've experienced periodic, painful episodes of lost or incomplete files. Here are a few highlights:

• A project's root.fpj file suddenly drops dozens of topic files.
• One or more topics lose up to 60% of their content.
• Topic files get three NULLs added at the top of the file, making RH think it's a binary file. (You can't see the NULLs in the RH HTML Editor or in Notepad, but you can in Notepad++.) Sigh...

And yes, I've reported this to Adobe.

Leon