[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: MVR Raju
Subject: Re: Merge changes made in a branch of repository-1 to a branch in repository-2 ?
Date: 1 Feb 2003 16:17:47 -0000

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]