Automatically updated code/data directories

In my research group, we're using SVN in a slightly non-standard way. We're using it to share and version both data files _and_ the code that created this data. The data files and directories that we put under svn control are typically large objects that get recomputed only once a great while. (The code that we version is modified more often and changes are checked in more often.)

Or at least, this is what we'd like to be doing. The problem is that when the data file that we want to version is actually a directory (often the case), and is computed as the result of running some script, there's a conflict with the operation of SVN.

Specifically, suppose a data directory D is already under SVN control, so that it contains a .svn directory with the repository information. Now, suppose D is the result of running a script. If that script is modified, it may occasionally be re-run to make an updated version of D that overwrites the old version (and once in a while, a user will be authorized to check new versions of data). In this case, the re-made version of D will not contain the .svn data and the repository information is lost, leading to inconsistencies.

So my question is, is the following a valid "SVN-safe" procedure that could solve this problem:

Basically, can we just copy out the .svn directory in D (and the .svns inside any dirtectories in D), and then simply copy them back in after the re-making of D? Will this properly preserve the SVN control of the files, and the relevant SVN repository information?

If this is not the solution, could you point me to one, or alternately explain how it may be difficult/impossible to find a solution at all? (I know that versioning computed data with SVN is unusual, and our problem is the result of doing this. But it seems to make sense for our application.)

Thanks!

Dan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1024467

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-14 18:59:38 CET