> I have to implement a versioning system for my company, but the > problem is that there are very many files involved.
First question is: is this actually a problem in practice? Computers have lots of disk space. Arch is fast and efficient, and is superfast when used with revision libraries and hard linking. And, once a developer or a tester has fetched your entire tree, updates are done incrementally. Getting the entire tree the first time might be slower, but updates are still fast. So the first thing I'd try is to put everything into an archive, and see if it worked fast enough for me. > The structure of the environment works with different layers (one > for our software vendor, one for customizations FROM our vendor, and > one for all our own developments). These are also divided into > subcategories for each site, because not all software is for all > sites, and a CORE for something that is for all sites. I'd suggest starting with two arch projects. (To avoid confusion around the word "project", I'll use "arch project" to refer to an arch project tree, and "development project" to refer to your own individual development projects). The two arch projects I suggest you consider are: * one that tracks code from your software vendor * one for all of your own developments Then, * Have a branch off of the software vendor tree to track your customizations * CORE and the the site categories are simple subdirectories within the second arch project * Have separate branches for testing and production * Have separate branches for each individual development project > Furthermore, for every site there is a production and > test-environment. The test-environment only contains software that > is in test, when it is OK, it will be removed from test and put into > production. The test environments also look in the production > environment for all object-files it hasn't itself. This sounds like something I would do if I didn't have a version control system yet. But life is simpler with a version control system like arch. Do your development in an individual development project branch. When you think the development project is ready, merge those changes into a testing branch. When the changes have passed testing, merge those changes into your main production branch. All within the *same* arch project. > I came up with the idea to work with little projects. Develop in a > project, copy source from the destination environment, or create > new. Then, when finished, it must be delivered to test. Sometimes > there must be more changes after testing, so it must be redelivered to > test. When testing completes, it will be delivered to prod. Yes, "working with little projects" is an excellent approach. And you can have a branch for each and every little project. Branches in arch are cheap and easy. It costs nothing to have lots of them. So why do I suggest having two arch projects, not one, or not many? I notice that there's a tendency among people new to version control to think of putting everything in different arch projects, or "repositories" as they're called in CVS. "We have this library and this core code and these different things we're working on and let's put them all into different arch projects (or repositories)". Unless there's a *reason* that you *need* to put things into different arch projects, I suggest putting everything into a *single* arch project. Fetching, commiting, branching, merging, everything in arch is simple with one arch project. One area where you will most likely need more than one arch project is when you have code crossing organizational boundaries. You're tracking code written by your software vendor, and it is much easier to track a non-arch project when you have an arch project which is dedicated to that one task, and is doing nothing else. Then your own customizations can easily and naturally be put in a branch off of the arch project containing the software vendor code. I hope this helps, Andrew Wilcox _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
