tags:

views:

280

answers:

3

I currently have a java library in subversion under package:

com.company.product.foo.*

Unfortunately, I have to refactor this into:

com.othercompany.bar.*

That'd be fine as a one-shot. But this has to be performed only on a specific branch. The problem is then to merge changes from trunk to the branch with totally different names.

The only solution I see would be to create a patch file, run some search & replace and then apply it on the branch.

Is there any better option ?

A: 

I can't see any really good solutions, but would it be an option to just create subclasses under the new package name?

Then the patches could be applied to the super classes, and the sub classes would never actually contain anything.

Nils-Petter Nilsen
Interesting idea but for legal reasons, we can not leave the original package name anywhere. This solution would require us to ship the original code along with the "wrappers".
Eric Darchis
+2  A: 

The first most obvious solution is to not use either company name as the package, but rather a trademarked name, or a neutral domain name that would be used going forward.

If that isn't possible (as in the customer doesn't want the two code bases to be seen as connected) the next most obvious solution is to use a source control system that is more friendly to the concept. Git might have better options, or perforce.

If you have to stick with subversion, then I would have it in source control under a neutral package name and then have the build process that checks out the code, moves it, renames the packages, and compiles, once for each company. Or If your IDE can understand it use a Java pre-processor.

Of course, that last one only works if both customers stay on the same base, but if not then the customer would have its own branch, and the build process could copy the code only as appropriate for the correct branch.

Yishai
I ended up using git with the SVN and it works pretty well.In fact we were using a trademark name but when the code changed hands, it also needed rebranding.
Eric Darchis
A: 

A good IDE with refactoring capability will be able to handle this in an instant. Once you make the change, commit it to Subversion. One of its strengths is that it treats directories and files the same way, so you can keep the history as you rename packages.

Sounds like you'd want to create a tag for the original; check out and refactor the trunk; commit the changes. Voila - old and new, with the refactored packages on the trunk where they belong.

Perhaps I'm misunderstanding your question, but I don't think you should make the change directly inside Subversion. Change the code and let Subversion do its job.

duffymo
Except he wants to be able to merge changes between the two branches, and the different packages would be flagged as changes on merging, so would be overwritten.
Mike Cooper
I'm assuming that the tagged version will not be modified once it's put in place, and all future changes will be made on the trunk only.
duffymo