Peter,

We are having good success with SVN.

The key for us is to accept that there is no acceptable merging solution other than manual copy and past, but thanks to Mike Yearwood's suggestions, we have not had too many collisions.

Mike suggested that we break out each class into it's own classlibrary so that an entire library isn't locked up while someone works on a single class. That has been critical, and we have been doing that as needed.

For us, there is no way to avoid collissions entirely. We may have one developer working on an enhancement to a class in a branch, while another fixes a bug in the same class in a release (and the trunk). Or another developer will be working on a separate enhancement in the same class in another branch.

To minimize this issue, we have instituted 3 practices:
1) Users must lock files before making changes. They must lock the file in both the Trunk and the Branch in which they are working.
2) Anyone may make a change to even a locked file, but they MUST use a specific commenting convention to easily identify the changes. They then must email the lock-holder of the file with the changes, which the lock-holder then merges in by copying and pasting (identifying the methods via the comment convention).
3) Everyone must update and commit several times a day. If you're working on a branch, you must update from the Trunk at least once every few hours.

It has worked out pretty well so far. We really like SVN, and are planning on sticking with it at least for the foreseeable future. It is a bummer that VCXs are binary, but it's easily worth the trouble to be able to use SC.

Hope that helps.

David

>From an earlier thread (ID: 1045693):
>
>---------------------------------------------------
>We are just starting using SubVersion. We use the TortoiseSVN client, which is surprisingly user friendly.
>
>Because of the binary nature of the VCX, we have struggled mightily so far. Christoph's suggestion of converting the XML and doing diffs sounds promising, so we may go that route. I am nervous about corrupting our classes, but I have also been following Christoph's work for years, and I know few people know the way VFP works like he does, so we will probably give it a whirl.
>
>Mike Yearwood's suggesting of atomic VCX's may also work well.
>
>Feel free to check in with us to see how we are progressing!
>
>Take care,
>
>David (Marlin #032217)
>-----------------------------------------------------------
>
>David, we are well on our way to using SVN with Tortoise. Here is a note from my partner on what he has learned.
>
>***********************************************************
>We too are starting to use SVN with VFP. I found two solutions here in the Universal, Push Ok, and scX.
>
>The Push Ok is a general plug-in for the Visual Studio environment that converts the Microsoft SCC interface to the SVN client interface. It generated a number of warnings and would generate GPF's in VFP 9 if I picked the wrong options. It also uses the Visual Studio versioning commands so it assumes a lock approach to version control rather than a copy-and-merge, like SVN folks tend to like.
>
>The scX Tool from Paul McNett (PaulMcNett.com) is looking much better. It is based on Microsoft's SCCTEXT.prg as modified by wOOdy (Juergen Wondzinski..) This is looking good. I am just now restructuring a large project to a new directory structure, then I am going to apply the scX to archive it all as text.
>
>So I will keep you up-to-date as I make progress!
>
>-Dale
>***********************************************************
>
>We are quite interested in your experience in using SVN with VFP.
>
>I invite further discussion from any VFP folks who are using SubVersion (SVN).
>
>Peter