Adam Turoff wrote:
>
> On Wed, Sep 13, 2000 at 09:59:09PM -0400, Barrie Slaymaker wrote:
> > Adam Turoff wrote:
> > > > Feedback welcome.
> > >
> > > I noticed that CVS reports this as part of the version logs:
> > >
> > > date: 2000/09/13 05:49:30; author: cvs; state: Exp; lines: +19 -19
> >
> > Yup: not sure how to orchestrate logging in to the server as different usernames,
> > or su'ing to be different users. Suggestions welcome.
>
> Well, use CVS, not su.
the su was for when not using the pserver, since I'm not sure whether CVS uses
your UID, or some environment variable to grab your user name when not using
the pserver.
At least, when using the pserver, you can log in under all the userids and
pass them in CVSROOT.
> The best solution I could think of is having a scratch area set aside
> for each committer. That way, when a patch comes in from gsar or jhi,
> the cvs sync is something like this
>
> cd cvs-scratch/jhi
> cvs up -A ## Sync to the current state of the repository
> <apply patch>
> cvs com
> cvs tag r_<perforce release number>
> cvs tag Perl<Perl release number> ## If applicable
>
> That presumes that cvs-scratch/jhi was instantiated like this:
> cvs -d ":pserver:(jhi|gsar|...)@loalhost:/cvs" co perl -d cvs-scratch/\1
vcp's using a single scratch dir right now, I wonder if it could simply
tweak CVSROOT before doing all the 'add', 'edit', 'remove' and 'commit'
commands. Or perhaps just before the 'commit', would need to test.
> Yeah, it's ugly, but disk is cheap and Perl is easy.
> Of course, the release times will be off, and time travel is left as an
> exercise for the reader.
Time travel patches welcome ;-).
> And that sync script could be run as nobody, not root.
It's run as me, right now, not as root. And no comments about how close to
running as nobody that is, heh.
> Oh, and you have to use cvs passwords, not "if you can see it,
> knock yourself out" access.
I do. This is all done with IPC::Run calling the cvs program.
> One disadvantage is that synchronizing branched development is a wee
> bit tricky. Use caution, and the appropriate amount of Scotch.
Scotch (as in the tape) will be necessary for branches. I'm totally ducking
that issue until vcp is up, stable, and useful without branches.
> Yes, but when 'jhi' commits a change from [EMAIL PROTECTED], CVS logs that
> as jhi's change and annotates it as such (see 'cvs annotate').
Yup. It should be easy to add a filtration hook to vcp to allow the user_id
field to be munged on the way from the source to the dest. Actually, if you
write the deltas out to a RevML file, then a XPathScript/XSLT/perl -pe could
do that today. But it would be nice to be able to instantiate a perl class
as a filter based on a command line option.
- Barrie
