Need SVN advice

I’ve used version control for a long time but mostly file-based systems like PVCS and QVCS. Also a solitary developer, I don’t have much real experience with merging or branching. I’m trying to get used to SVN (using TortoiseSVN in PhpEd) since that appears to be the VCS of choice here and I think I’m adjusting to its directory-based way of doing things, but I could use some advice on how to set up the spam-proof form snippet I’m working on (called SPForm).

I’ve created a repository in a mydocuments folder called spform, with /trunk, / branches, and /tags folders. My working copy is in the MODx site tree in /assets/snippets/spform where it has to be to test the code.

Here’s the problem, though. I have a couple of configuration files that need to have local info in them to work on my machine. Obviously, the distribution versions will have generic examples instead of my local stuff in those files.

Here’s what I’m thinking of to deal with this.

1. Create a branch (called, say, generic) and copy the head version there.
2. Create a new generic working directory and check out the branch there.
3. Edit the config files to include the generic info.
4. Commit the changes to the branch repository.

From then on, I’d work on the trunk for any changes to the snippet and merge those changes into the generic branch.

Then, when I want to distribute a version, I can export from the generic branch in the repository to an empty directory and zip everything up.

Does this make sense, or is there a better way to do what I’m trying to do?

Would I have to leave the generic working directory in place, or could it be deleted?

Bob

I’m by no means an SVN expert but the way I would do it is use the branch as the ’bleeding edge’ version of the code and merge across to the trunk for the stable release.

For your config file, commit the generic version and then add your local copy of the config file to svn:ignore - that means it won’t get committed by accident and overwrite the generic version that you have in the repository. For changes that would affect the generic version of the config file, you could check it out, change, remove from svn:ignore, commit and then put it back to svn:ignore.

Then, for releases, you can just check out from the trunk and package it up (creating a tag at the same time to mark the release version in the repository)

Like I say, that’s how I’d do it ... perhaps more SVN savvy people can give some input.

Thanks! That sounds like it might work for me.

Does svn:ignore go in the properties for the individual file or is it a project setting (I’m using TortoiseSVN if it matters)? I assume it blocks both commits and updates?

I don’t think my original plan would work. Committing changes from the trunk would overwrite the generic configs unless those files weren’t under source control.

I did consider not adding the config files to source control but I don’t like to do that if there’s another way (and it’s too late anyway ).

Bob

The usual naming scheme for generic config files is [tt]config.php-dist[/tt]. All you do is add "-dist" to your generic config file and then make a new config without "-dist" for your local config file.

’svn:ignore’ is a folder property, as described in Subversion Properties Documentation.

Enjoy!

Quote from: sirlancelot at Oct 29, 2007, 05:10 PM

The usual naming scheme for generic config files is [tt]config.php-dist[/tt]. All you do is add "-dist" to your generic config file and then make a new config without "-dist" for your local config file.

’svn:ignore’ is a folder property, as described in Subversion Properties Documentation.

Enjoy!

Thanks!

It’s a thorny problem because, at this stage of development, the config file may undergo major changes with variables being added and deleted, so I’d like to have it under version control.

It’s a fairly large file with lots of options that I need to turn on and off to test things. The problem is that the one I’m working on has to be the local version. It would be somewhat perilous to try to merge the changes into the -dist version (especially without merging in the strictly local changes like my email address and server name).

Also, the -dist version will have all the variables set to their default settings but the one I work with won’t.

I think I’m probably going to have to do things the old-fashioned way and just merge the changes in very carefully by hand. Your suggestion of having an extra file is really helpful, though. I hadn’t thought of that.

Here’s the big questions: Would both files normally be under version control?

BTW, in TortoiseSVN you can svn:ignore individual unversioned files. I’m not sure if that option is available on the SVN command line, but this is from the TSVN help file:

If you right click on a single unversioned file, and select the command TortoiseSVN → Add to Ignore List from the context menu, a submenu appears allowing you to select just that file, or all files with the same extension. If you select multiple files, there is no submenu and you can only add those specific files/folders.

Bob

Quote from: BobRay at Oct 29, 2007, 10:26 PM

BTW, in TortoiseSVN you can svn:ignore individual unversioned files. I’m not sure if that option is available on the SVN command line, but this is from the TSVN help file:

That’s the GUI interface for the svn:ignore property. svn:ignore is basically a file containing a list of filenames that SVN should ignore. The property is associated with a folder. But you’ve got the idea