Hi Casey, I think I understand what you want to do, but it needs a fair bit more effort to set up than on other systems. I'm guessing you've got a Utility.java file or something similar in which you throw common useful functions to reuse across apps.
Here's one problem with just using a shared file, as you would in VSS or similar: you have a utility function called: Folder getDesktopFolder() and you update it to have the following definition, to account for a weirdness on NT systems: Folder getDesktopFolder(boolean usingNT) Now, you have to check every app which uses this file to make sure it still compiles. A change to a shared file must _always_ be reflected in other code. Using the shared project approach, you can solve this problem and future proof your apps. Make a build script which includes: cvs co -rSHAREDLIB_VERSION_5_FIXES sharedlib as a line. Then, users needs to run build.bat or build.sh when they check out. SHAREDLIB_VERSION_5_FIXES would be the branch tag of all compatible changes to the library sharedlib that this code requires. You would not want to automagically copy the utility file into your own directory, since you can't then check changes back into that branch. (on *nix you may be able to use a symlink to do the same thing though). You could then commit fixs to the library and the changes would reflect in other apps. Now, for an incompatible change like the above one, you would make a new branch, and check that version out. Other apps will still use the old branch of the file, and not require updating. Note that if most of the time, you are making compatible changes, like adding functions, fixing bugs, etc., you don't need to worry about branching. It's just when old clients would get broken. If you have a project folder format like: project/ main/ docs/ testscripts/ sharedlib/ build.sh then the sharedlib folder fits in nicely. Advantages: - You can fix your libraries while you work without needing to redeploy or release manage etc. - You can fix the same bugs in other apps - You don't have to worry about chasing up every other app to resolve incompatibilities - Developers won't do the same silly things to the shared code as they might to their own (like decide to fix function name capitalisation in a case-sensitive language) Disadvantages: - Could be a pain making those branches (maybe a script would help) - Can only use "cvs tag" in this repo. In our shop, we have a central library that developers from our company and different clients we contract to commit to. Keeping it separate, in our experience, improves code quality since the code is in a way "published" and people take more care. Anyway, just some thoughts... HTH Regards, Matthew Herrmann -------------------------------------- Far Edge Technology Level 11, 80 Mount St North Sydney NSW 2060 Australia _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
