Re: CVS (slightly off-topic)

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sep 8, 11:40am, Adam Spiers wrote:
} Subject: Re: CVS (slightly off-topic)
}
} On the subject of CVS, I've been trying to get my head around (vendor)
} branches and have been wondering what the best strategy would be for
} using CVS to track changes.  I know that several of you are already
} doing this; would you mind briefly detailing what strategy you use?

I have two repositories, one for zsh-3.0 and one for zsh-3.1.

I import full releases (e.g. 3.0.5, 3.0.6, 3.1.5, 3.1.6) on the standard
vendor branch with vendor tag "zsh-workers".

I import the pws-XX releases onto a second vendor branch with vendor tag
"pws".  I wrote a zsh function wrapper around the cvs command that checks
the vendor tag name and inserts the appropriate -b option so that I can't
accidentally import onto the standard vendor branch, which is the primary
problem with using more than one vendor branch.

(That wrapper function does other things like execute "rm -i" if I try to
"cvs remove" a file that still exists, and always use "cvs -n" with the
"diff" subcommand, and so forth.)

I apply patches to the main trunk as they appear on zsh-workers, and make
any changes of my own there as well.  Immediately after importing, I merge
in the pws-XX changes with e.g.

	cvs update -d
	cvs update -jzsh-3-1-6-pws-2 -jzsh-3-1-6-pws-3

The first update is to pick up any completely new files/directories,
which merging doesn't always accomplish.  Using explicit revision tags
in the update -j -j produces *much* better merges than does the stupid
"yesterday" suggestion that's spat out at the end of the import.

Then I resolve conflicts reported by the merge (ignore conflicts reported
by import, they're mostly useless) and run e.g.

	cvs diff -u -rzsh-3-1-6-pws-3

to check whether I have patches that Peter may have missed or that should
not have been included.  I resolve anything reported by the diff, then
"cvs commit", and now I'm ready to start applying patches off the list
again.

} If you wanted to merge in changes from the anon CVS to your own
} repository, would you have to update your working copy of the anon
} CVS and then `cvs import' your working copy into your own development
} repository, or is there a better way?

There are assorted tools for keeping two repositories in sync, but none
of them do much more than help you automate the process.  You don't have
to import, of course; you can check out two sandboxes (one from the anon
repository, one from your own), and "cp" files back and forth between
the sandboxes, doing updates and/or commits on whichever side is out of
date.  In that case it's good to make some helper scripts to prevent you
from copying a file over the top of one you've changed but not committed.

(You can't "cvs import" your own working copy; I believe cvs refuses to do
an import in a directory that has CVS/ subdirectories.  What you'd do is
"cvs export" from the anon server to a clean tree, then "cvs import" that,
and finally merge into your sandbox with update -j -j as I described.)

On Sep 8,  3:44pm, Ollivier Robert wrote:
} Subject: Re: CVS (slightly off-topic)
}
} There is only one vendor branch.

I don't want turn zsh-workers into the info-cvs list, but:

	cvs import -b 1.1.N ...

for any odd number N greater than 1, creates another vendor branch.  As
I said, you then have to remember to explicitly add that -b option every
time you want to import to that branch; the vendor tag name is not used
by cvs itself, though you're required to provide one.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com