How to maintain code so that it can be used in multiple software?

230 views Asked by At

I need to understand the best practices to use the same source code/libraries into multiple applications. The requirement is, e.g. I am selling my code/library to some company, lets say xyx, then I should use xyz as company name in my packages(and other places if required).

Later, if some other company pqr wants that code/library, I need to manually go and change all package names(and others) again and create another repository in source control software. This task is very time consuming and not good at all.
Whenever I find a bug in base code, I need to commit changes in all copies of the same code and release library to all companies.

I am trying to find how should I approach such situation.

I am here talking about some Java packages (contains very basic features that I wish to use in all company's software), and I am using tortoise svn as repository.

1

There are 1 answers

1
VonC On BEST ANSWER

If you are selling the code/library, that means you are providing a delivery resulting from a packaging operation.
In other words, you don't give the repo itself, but a packaged set of files (like, for instance, an archive, a zip file)

That means the sources versioned in your repo don't have to include the company name. They can include a template field (like @COMPANY@), and a script able, on checkout of that code, to put the right value in place of that template field.

In git, this is called a content filter driver using a script declared in a .gitattribute (as in here), and storing the actual value outside the git repo (that way, they cannot be pushed by mistake)

smudge

(image from "Customizing Git Attributes" from the Git Book)

With SVN, you could consider using "Keyword Substitution".

In both cases (Git or SVN), the idea is to version source files with @COMPANY@ in it, and to generate on demand the right valued files whenever you need to release that library to a client.

Don't mix development (which happens in your Git or SVN repo) with release management (which can use a different process, like a file representing the name of target company, used to value the source files. If that file isn't present, the source files remain unchanged on checkout)