Basic rules for selecting a version control system (vcs)
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1) The data that you create will live on far longer than whatever vcs du
jour that you happen to pick. It doesn't matter which one you choose
because at some point someone will obsolete it and move the data into
another system.
2) All VC's provide three basic functions
a) The ability to clone a file hierarchy onto another system where you
can get data redundancy and backup storage.
b) The ability to distribute a file hierarchy to a 3rd party by
pointing them to the central store where they can get the bits without
bothering you.
c) The ability to restore the file hierarchy to the exact state that it
was in at any point in the past.
3) Version control systems compete by adding features above and beyond the
three basic ones such as branching and merging. DO NOT USE THESE
FEATURES!!!!! If you do then you will be in trouble when the day comes to
move the data out of the old vcs and into the new one. On that day all you
want to do is dump out the change history logs into ascii files, strip out
all the old .svn,.cvs.git directories and then check everything into the
new system. Do not worry about losing the ability to restore back to any
state from previous systems. If you need that then hang onto a archive
copy of that database.
Some features like the ability to detect if a single bit in the database is
corrupted can be used because they are useful and do not effect porting the
data to a new system.
4) If you are working on a large project then you will have to use several
different version control systems depending on the whims of the developer.
Learn to live with it. On the other hand when you are doing the development
then you can pick your favorite.
5) When you receive a repository for a component that you are using in your
design then do not add those files into your repository. Store it in a
folder marked with the developers name and simply link those files over
into your development environment. That way when the component is changed
all you have to do is update to get the latest. Be sure to remember when
you checked out the original repository because if something breaks you
might have to restore back to that point.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
So you want to keep your databases small and dedicated for a single
purpose. You don't want one repository that contains everything that
currently is or every was part of the project. That should simply be a list
of where all the repositories are that contain that data. When you check
out a complete openrisc design you will need a script that retrieves
probably about 20-40 different repositories from the net. Having up-to-date
clones for all of them on opencores.org would be a good idea.
John Eaton
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
