Hi Andrea,
In reading your original description:
We are trying to keep track of all the modifications we make to some
input files for our reservoir simulator, in order to not lose the
history of our work and to be able to retrieve in the future old
results. The possible modifications are endless, so it happens that
after few months we are lost because we can not recover the exact
input file that generated a particular result.
I, like others, thought it sounded pretty much in the ballpark for a modern version control system like SVN. Such systems are designed to work with multiple files being continually modified, by an individual or a team, and have two main objectives: keep track of the history of modifications, and facilitate team development of changes to the file set. They also allow determining just what changed between any two versions, which may be valuable to you.
You say
> 2) We don't have a "central repository" *and* "a working copy" of it:
> the two main directories hold about 2 TB of data, and though I am
> interested only in input files, we can not afford to have a working
> copy of the central directories;
With SVN (for instance), you only have working copies of the files or directories you're working on at any time. If the repository is well organized, it's pretty easy to check out just the parts you need.
> 3) The software itself must be as simple and as fast to use as
> possible: I am the only "programmer" of our group of reservoir
> engineer (though I am only an amateurish-like Python coder), and we
> honestly don't have a lot of time to play with the software, or the
> work will deteriorate.
Under Windows, TortoiseSVN integrates into the Explorer with a right click menu, as you mentioned; it's pretty straightforward, once you have the basic concepts.
Also, no database system automatically gives you the kind of versioning, history, differencing, etc. that you get with a version control system -- you can create it, of course, but _you_ have to create it.
My feeling is that there are pretty sharp tradeoffs between starting with a DB and rolling your own vs. adapting a version control system to your needs. I'd recommend educating yourself a bit more before committing to one door.
> Knowing nothing about SVN, as we are working across 2 networks, will I
> need the support of our IT to set-up everything? If the answer is yes,
> that will definitely kill the SVN idea. I still have to find (in
> London as in Italy) an IT that is competent enough to avoid to screw
> up what we have done or that is able to make changes fast enough for
> our needs.
If both your London and Italy teams will need access to the same set of files, you'll need some competent IT support to set up and maintain your "file base" anyway, whether a SVN repository or a "heavyweight" database system that supports multi-user access with transactions, etc. (In this case, you should be looking at PostgresSQL, Firebird, or maybe a recent version of MySL.) I wouldn't make that a prime determiner of the direction you go.
One last suggestion: if you have access to Access (or OpenOffice Base), do some prototyping in it. It's a quick way to get a feel for the nature, power, and limitations of the relational model.
···
--
Don Dwiggins
Advanced Publishing Technology
