Usage scenario for svn branches

I have a product that I dis开发者_运维百科tribute to my clients. Each client needs some UI customization. I want each client to be able to get updated with new version easily.

Can I create a project in svn that serves as a "base project", and then create branches for each client? With that said, will I then be able to commit changes in a branch to the branch, with the option of pushing that change to the core? Can I also perform and "update" command in a branch that will only update changes to the core?

Mahesh has the right answer, you'd create a branch for each, and merge changes back from your trunk whenever you want to do the release.

I'll throw out some advice though: avoid doing this!

Inevitably, because you can customize the full code, you will. Even "UI changes" can cause issues -- if you modify the same piece of code in trunk and a client customized branch, it will cause a conflict that has to manually be resolved when you merge. As you get further along, changes will become more and more complicated, and your branches will get further apart from trunk, feeling more and more like a totally different product than a customization.

Consider the scenario: you need to introduce a new feature, or want to refactor an existing one to fix some bugs or just make it easier to maintain. This change however, will break existing code (eg other features). When you have a single code base, at least you can see where it will break, and what you need to do to fix it. When you have multiple branches that are all customized, that visualization is not possible.

A better alternative is to look at exactly what you need to do for all these clients, and build a framework to allow those customizations, while still keeping one code base.

If all you want to do is change the name in the title bar, and a couple images, just create a config file (.ini, or XML, or whatever) that allows you to specify those things. Your application reads it at startup. Now you have one codebase, and you just swap out the customization file for whatever client during deployment.

If you need to customize the layout of the GUI (typically called 'skinning') there are pre-built frameworks to help with that.

On the far end of the spectrum, if you REALLY need to provide code customizations, do it using a plugin architecture. Build interfaces that provide the basic API, and then for each client, build them a custom library that implements that interface but has the custom parts for each. You can put controls, code logic, etc in the libraries.

Details are beyond the scope of this question, but you can do pretty much anything with this, without having to get into the problems that multiple copies of (mostly) the same code will introduce.

Yes, you can do all the things that you mentioned with svn!

You can "merge" branches to the core specifying the start and end revision numbers that you want to merge to the trunk (core).

Branches act as separate thing from your trunk(core), so when you commit to a branch the changes just reside in the branch, unless you explicitly merge it to the trunk.

The nomenclature I have seen so far is to have 3 base directories:

• trunk: Your core
• branches: All work branches
• tags (or releases): All different version release. Basically, everything you gave a customer should be in there.

This usage does not overload the server: identical files are kept once, not one for every branch. This is transparent to you as a user when you update.

When you need to bring some change to the trunk, merge the trunk onto your branch first (to make sure you have the latest from the trunk), then merge the branch onto the trunk. (Make sure you haven't erase anything inadvertently in the process).