[Top][All Lists]

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

Re: newbie usage question

From: Max Bowsher
Subject: Re: newbie usage question
Date: Sun, 27 Apr 2003 22:20:05 +0100

Terrence Enger wrote:
> At 17:33 2003-04-27 +0100, you wrote:
>> Terrence Enger wrote:
>>> So far as I can see, the obvious scheme is to set up my own repository,
>>> where I can record my own work, and to treat the official source as
>>> distributions.  However, this provides no assistance for contributing
>>> patches back to the official source. That is to say, I would checkout
>>> official source into a separate work area, apply my changes, submit a
>>> patch, and eventually deal with the conflicts when I update my
>>> work-in-progress from the the official source.  Well, now that I wrote
>>> down in so many words, it does not look like such a big deal.  Still, I
>>> would welcome better suggestions or confirmation that this is a
>>> way to proceed.
>> Why not:
>> Make a script that regularly cvs updates an unmodified working dir from
>> cvshome, and if there were changes, imports it into your local
>> and mails you a reminder to merge from the vendor branch. (Make sure you
>> make good use of tags so you can always merge the right changes without
>> fuss.)
> Ah yes.  <musing>I make my living writing programs for other people.  Why
> should I hesitate to write a script for myself?</musing>
>> Then, simply:
>> cvs rdiff -r VENDORBRANCH -r HEAD
>> (or just cvs diff -r VENDORBRANCH in your changed working dir)
>> CVS will take care of day-to-day merging, requiring user assistance only
>> conflicts - which won't happen very often.
> And then feed the output into patch?

No, use diff for preparing a patch to submit for inclusion. Use update -j
for merge work.

>  Would it be okay to do the following
> immediately?:
>     cvs update -j officialrelease1 -j officalrelease2

Yes, but only if you are prepared to resolve any conflicts that occur before
doing any further development in that working directory. Also, I'd suggest
you check for uncommitted changes before doing upd -j. It is easier to
understand the history of a file if merges and development work aren't mixed
in one commit.

> Thank you, Max, for your help.  Time for me now to do a backup and start
> trying this.

No problem.


reply via email to

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