Re: Merge changes made in a branch of repository-1 to a branch in repository-2 ?

[MVR Raju]

We essentially have two configuration subsystems (two directories 
in a module) to be synchronized, from time to time, across 
repositories. It is not exactly to synchronize multiple 
repositories, but to get all the fixes committed (in those 
directories) to main line/branch in repository-1 to main line of 
repository-2. repository-2 might have changes to files in those 
directories private to itself.

To start with, we plan to copy files in these directories from 
repository-1 to repository-2. This will ensure the version changes 
are seen even in repository-2 and we have common greatest ancestor 
revision for each file in these directories.

After copying, we tag the main line/branch of repository-1, time 
to time, to help us in merge process. We keep tagging repository-2 
main trunk as well. I require to cross merge (changes made in 
repository-1 to repository-2) and support recursive behavior down 
the directory tree, as with other CVS commands. I have source for 
cvs 1.11.1p1 and I started changing cvs implementation to support 
my requirement (right now works for local CVS). I am planning to 
extend this change to support Client/Server model. Here is how it 
goes.

Client: If a special flag (e.g. -x for cross merge/expert mode :-) 
) is supplied with command line at client, client will send server 
(along with regular requests), the file contents even if the file 
is unchanged (we force this to happen). The command syntax would 
look something like "cvs -d <path_to_repository-1> update -j 
<tag-n_for_cross_merge> [ -j <tag-n+1_for_cross_merge> ] -x 
<file/directory>". This command will be issued from the tree I 
checked out latest, from repository-2.

Server: It parses the request and calls "update". Server works on 
repository-1 as we specified -d with update.

Server: server checks the state of the user file and performs 
merge with RCS file depending on the tag/date supplied. This step 
would happen even if we don't specify -j option(s) in normal case. 
We will prevent this step in special case (change CVS 
implementation). What happens if we don't : user file gets merged 
with head revision (or a revision derived from tag/date) on the 
repository specified (which might have lots of changes made to 
repository-1 file).

Server: Finally if -j option(s) are specified, extract the 
revision(s) of -j option(s) and do diff3 on the file from previous 
step. The merged content of the file is sent back to client.

I have tested this stuff (local CVS). It looks it is working fine. 
Normal behavior of "cvs update" is unaltered, if -x is not 
specified with cvs update.

This is what I felt and did. Can someone comment or help me with a 
better approach. Am I wrong somewhere? I am yet to do stuff to 
support -x on Client/Server model. I am yet to go through few 
special cases to handle.

Major issue, I guess, would be : my CVS binary has to run as 
server (so that it understands -x with update) and engineers 
responsible for this cross merge need to run my CVS binary 
(client). But I hope, this would reduce synchronization time.

Thanks in advance.

with best wishes,

Ramaraju Manthena

address@hidden