Merging changes from one repository to many others_问答_开发者

I'm going to give some information so you can understand where i'm at with this so bear with me:

I've started working at this workplace 4 months ago now. They have an inhouse catalog engine that can be installed on many hosts. I brought in SVN because i'm relatively used to working with it, merging, branching and stuff like that.

The big problem with the catalog is that the core code that should be shared between all end users is crap, very crap. You can't really have a core by itself, it comes with the templates, the config and everything else all mixed up.

Further more, my boss, wants to split all the different clients into different repositories (Which i might say is logical) but because i can't have one main copy of the catalog, it becomes hell when i need to merge changes from the main repository to the different clients. A simple 1-10 line change can be done in the 9 catalogs, but today i'm being tasked to add a whole payment processor feature to it and it gives me about 700 lines in 35 files to modify...

I tried searching for an hour now on how to merge or replay changes from my main branch @rev54 to any other repository @rev??? but all i get are extremely long wait times and conflict reports or i get problems saying "X isn't in repository Y" messages.

Here is what i tried:

Search: Svn merge changes across different repositories Search: Svn replay changes to another repository Search: Svn merge repository changes

Read countless posts on StackOverflow

Read countless blog posts

Tried: cd client1/cat/; svn merge --dry-run http://svnserver/svn/mainbranch/trunk@54 Tried: cd client1/cat/; svn merge --dry-run http://svnserver/svn/mainbranch/trunk@54 http://svnserver/svn/clientbranch/trunk@5 .

Looked at "advanced merging" documentation from svn redbook too, nothing seems to give out simple "replaying" results.

All i want is to take changes from REV54 from main branch and apply it to other catalogs at different revisions but with very similar source code. (Some templates may开发者_运维百科 be customized)

Ok well after all it seemed harder than it really was, i was able to get it off with a simple:

CD "directory you merge into"
svn merge -r"lastrev":HEAD <URL TO THE PATH TO MERGE>

And it worked. I did get a truck load of conflicts but that was related to the changes i was trying to merge and some already existed in that new project but overall i think i did get it right and i will be able to apply core changes to all catalogs from now on.

Obvioulsy, as fast as possible, we'll get a core going that can be subdirectory checked out but for now, this solution will work.

Hope it helps someone later

Not what you want to hear, but this type of scenario would be easier with Git, or HG.

In git what you're talking about is a central repo that all client repo's could merge from and just have it as an additional remote that they'd occasionally fetch/pull. Or alternatively you could use the cherry pick command to move a change from one repo to another rather easily.

In SVN I would guess that this is most easily done by exporting patches and applying them to the clients while hoping they work properly, I never remember a large Svn merge that went smoothly though.

edit: Depending on what is "core" you could use SVN externals to have all the core files in the same repository. But that would remove per client changes to what is core.

You could have a single repository that contains all the clients.

For example:

/core/trunk/....
/client_a/trunk/...

It might also be worth having a vendor branch for each client:

/client_a/vendor/...

The vendor branch in client_a would /core/trunk (or /core/branches/etc) from the last merge. Normally one would use a vendor branch to track changes from an upstream repository when you're then making your own modifications. This allows you to later merge in changes without conflict from the upstream repository in to the vendor branch. Once in the vendor branch you can easily diff the current vendor version with the previous to calculate what changes you need to make.

You can view your per client problem as variation of this problem. Where core is the upstream vendor, and each client is the downstream with their own customizations.

If you cannot create a single repository, then the above still applies. Again treat "core" as an upstream vendor branch. When pulling the changes in to a client specific repository checkout that client's vendor branch and replace all the content that's currently in there with the latest copy from core then commit. After this you can merge the different between vendor@head with vendor@prev in to that client's trunk.

See, Vendor Branches from the Version control with Subversion book.