Re: Sharing a file between to different modules (A dead-horse topic?)

[Matthew Herrmann]

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