Hello, I am in a bit of a quandary. I use CVS to manage repositories for multiple clients on a single server. Each client has his own repository on the server, so I don't have any issues between my clients' repsitories. Until now, each client has had only one product, with the main trunk and all branches or his particular repository relating to that single product. However, I now have a case where one client wants to add more products to his the repository (he's finally getting his other products under revision control at my urging). So my problem is, how do I manage this in CVS? I'd like to keep a single repository for the client, with the idea being that any code that is shared between products won't have to be duplicated across multiple repositories. But (I think) I also want to be able to branch each product independently -- as ProductA might need a new release branch (and version) while ProductB stays the course on the main trunk or whatever branch is current for it. What I envision in the developer's sandbox is something like this: /sandbox /shared sources /trunk /branches ?? /product A /trunk /branch x /product B /trunk /branch y Obviously, this won't match the repository, which for the above hierarchy would probably look something like this: /repository /trunk /shared sources /product A /product B /branch x /product A /shared sources ?? /branch y /product B /shared sources ?? And then, of course, there's the issue of third-party libraries. ProductA might use version 1.0 of LibraryA while ProductB uses version 2.0 of the same library. It gives me a headache just thinking about all of this. Are there some best practices that can help with this sort of situation? Everything I have ever found on branching practices focuses on the development of a single product -- as if nobody ever has to worry about more than one product, which is just plain naive. How do others usually handle the situation of managing multiple, independent products (that might have to share code or libraries) on a single repository? Is it even possible? Am I going to be forced into creating a repository for each product? Perhaps that will be the best way to handle this situation, but it seems like overkill and seems like it would wreak havoc on the ability to have shared code and third-party libraries without duplication on the repository server. Another issue that comes out of this is how to checkout all of the code necessary to build all of the products in their various version configurations. For instance, if I want to get the source to create a new release, I might need Branch X of Product A, and Branch Y of Product B, and I would have no choice but to execute two separate checkout operations. I cannot define in any of the administrative files, that I know of, a way to say, "give me Release 2" which would checkout specified products and the appropriate branches for that release. I would greatly appreciate any ideas, suggestions, or links that would help me to make the right decisions as I contemplate this task. Thank you, - Dennis _______________________________________________ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs

Thanks for replying, Rob. Comments follow... "Robert Clark" <robert.clark@quest.com> wrote in message news:mailman.3329.1169244073.2155.info-cvs@nongnu.org... >> Obviously, this won't match the repository, which for the above >> hierarchy would probably look something like this: >> >> /repository >> /trunk >> /shared sources >> /product A >> /product B >> /branch x >> /product A >> /shared sources ?? >> /branch y >> /product B >> /shared sources ?? > > > Actually, for CVS, the repository might look something like: > > /repository > /shared sources > /product A > /product B > /3rd party > /library A > /library B > > with the branches and trunk being contained inside each file in the > repository. Yes, that is true for the actual physical implementation of the repository -- I intended to describe a *logical* representation of the repository (from a developer's perspective). >> Another issue that comes out of this is how to checkout all of the >> code necessary to build all of the products in their various >> version configurations. > > There is no single, magic CVS command or configuration setting you can > use that will cover this. I suspected as much. > What I do in situations like this is create > a shell script/batch file/Ant file/makefile/whatever that I add to > the root directory of the project. > This script (which is version > controlled along with the rest of the product) knows how to check out > the correct version of the rest of the code as necessary. > With they layout above, I generally tell people: > > - checkout whatever branch of Product A you want into an empty > directory > - run the update_sanbox script in the root directory of the > project. > > That update script is written so that it checks out all the correct > branches or versions of the shared common and 3rd party libraries to > the correct location in the developer's sandbox. Ah, I see. So a checkout of any particular product requires two checkouts: the first to get the required branch for your product, then a second checkout using the product's 'update_sandbox' script to get the appropriate branches of its dependencies. Then if the product's dependency on a particular version of another product changes to some other version, then you just change your product's 'update_sandbox' script so that it refers to the appropriate products/branches for its dependencies. That makes sense, though it could lead to significant subtree duplication (if multiple products/branches use the same dependencies) -- but I think I could live with that. Thanks a lot, - Dennis _______________________________________________ info-cvs mailing list info-cvs@nongnu.org http://lists.nongnu.org/mailman/listinfo/info-cvs