cvs is designed to work with a one developer/one sandbox model.
In fact I would argue that this isn't a cvs problem at all.
Why can't you have multiple copies of the tree?
In any event you have 3 choices.
1) Fix the broken scripts that don't allow you to work from
a base directory
2) Write a script that descends through the tree and modifies the
CVS/Root to the correct thingie
3) Continue to hand hack.
4) Don't develop on the "workstation" as you want to test something
there have a script that updates from cvs and then let the user
test...
In any event, what happens if two or more developers want to
do something in the same tree in the workstation? I would
seriously think about the model that you are using as opposed
to trying to retrofit cvs into the model that you are using.
donald
On Tue, Jul 25, 2000 at 11:32:28AM -0700, Stuart R Dole wrote:
> Here's a simple-minded question.
>
> I've finally got CVS sort of functional, and I'm running a
> "pserver" setup -- cvs on a Linux file server, and the
> client is a local Linux "workstation".
>
> I've discovered that when I cd into a working directory,
> after logging-in to cvs, that cvs doesn't like me to do
> things unless the name in CVS/Root is me. This makes sense,
> but since there's several of us that telnet into the
> "workstation" and modify files, each one needs to edit the
> file CVS/Root to match themselves. (I haven't figured out a
> good way to simply let each user have his/her own working
> directory -- there's one working directory on the
> workstation that we all share, because of the way all the
> scripts are set up... The workstation is really an embedded
> system with custom hardware on it that we're constantly
> testing.)
>
> So, is there a simple way to tell CVS that a new guy is now
> in the working directory and messing with the files, other
> than manually editing the CVS/Root file? If I do this, is
> there more I need to be doing too?
>
> (I have a sense that I know enough to be really dangerous
> now, but not enough to be very useful.)
>
>
> Thanks,
> Stuart
>
