Adding unversioned files to subversion

Question

Is it possible to add files to subversion that isn't supposed to be versioned? F.ex. config-files that needs to be edited to match each individual environment. When a new programmer is connected to the project he should get the original file from subversion but it wont be commited after he edits it and it wont be overwritten when he updates.

Maybe creating a tag for the whole original-project is the solution? First downloading the tag and then update from trunk?

Any ideas?

---

Clarification to comments below: The project (Sitecore) consists of about 30k number of different files. We need to version about 100 of these. If we should include all files in the versioning then each commit takes forever (as tortoise searches through all folders). Today we create a zip-file containing all the unversioned folders, sets the folders as ignore in svn and then add the zip instead. Problem is when we need to change one or more of the files in the zip, then we need to commit a new ~1GB-zip to the repo.

Answer 1

I would create a script that generates the configuration files when ran. This way, you do not need to worry about your SCM getting in the way.

Answer 2

Just use a templatefile for this. Suppose your file is called config.txt. Look at the file and insert some markers where local settings should go, rename it to configTemplate.txt and commit it. Then each developer should check out the file, make a copy of it, remove the template part of the filename (so everyone gets the correct config.txt), and add the new file to the ignore list. Then either let everyone simply manually edit in the local settings where the markers are in the template file or use a script to do it for them (if possible).

The template file is never changed (unless there's a difference in the format of the config file of course).

In reply to your edit (and comment):

Images, documents and binary files that are not automatically generated should probably all be put under version control. Or at least I don't see any good reason to keep them unversioned.

Answer 3

I'd put the unversioned files up on a web or file server accessible to everyone using the project, and add a script to automatically (wget/scp/etc.) download the files (zipped if needed) and extract them to svnignored folders so that they don't get picked up by subversion.

If you are concerned about these files changing, then: shouldn't they be versioned?

svn:externals may be useful in this situation too. I think they can be set up to be ignored easily as circumstances permit.

Answer 4

In some cases it is not even necessary to create a web.config per developer, as the .Net configuration format allows overriding specific sections of your config file via the configSource attribute.

The configSource attribute specifies a filename that (when the file exists) overrides the specified block and when it doesn't exist the block is used as-is.

<?xml version="1.0"?>
<configuration>
  <connectionStrings configSource="connections.config">
      <add name="LocalSqlServer" 
           connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"
           providerName="System.Data.SqlClient" />
  </connectionStrings>
</configuration>

On the developer system you can just add a connections.config with the connections for him, while the rest of the settings can be shared.

(So this doesn't resolve the issue of the templates, but it can help you manage a big template as many small)

Answer 5

You need to rethink how you're using subverion. Subversion stores version information about files; no more, no less. You can't store unversioned files in subversion; doesn't make any sense. Storing a 1GB zip into subversion isn't going to do anything good either.

You should look into a way the developers can override settings in this files via personalized configuration files in the user's home directory or maybe environment variables.

Answer 6

Let every programmer work on their own branch and let them merge their changes back into the main branch/trunk. Of course, your team mates need to be up to scratch using version control and be able to use more than just checkout, update and commit.