Re: newbie usage question

[Max Bowsher]

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
vendor
>>> 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
it
>>> 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
reasonable
>>> 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
repository,
>> 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
for
>> 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.


Max.