Victor Mote wrote:
Jeremias Maerki wrote:


Let's look at it the other way: Is there a downside to moving all the
files on the client and checking in everything? What do you guys think
would be the best way to accomplish such a thing?

The downside to moving the files on the client & then checking in is that
you have now disconnected the current files from their history.

I don't know how much access we have to the cvs server, but, if we have
enough, I think the preferred way to go is to 1) lock the repository down,
2) burn a copy of the repository onto a CD for backup & a permanent archive,
3) hack away at the repository until everything is as you wish, and 4)
unlock the repository.

However, the truth is that doing it the right "clean" way will be fine as
well. I don't think we have any pressing needs to be greatly attached to the
history. Peter has already documented how to leave an audit trail if you
move in the repository & a similar thing could be done using the other
method.

The '-m"comment"' option on 'cvs add' will set the descriptive text.

alt.design 8:04$ cvs add -m"THIS FILE IS BEING ADDED." junk
cvs add: scheduling file `junk' for addition
cvs add: use 'cvs commit' to add this file permanently


The '-m"comment"' option on the subsequent 'cvs commit' will set the log text on the first revision of the added file.


alt.design 8:05$ cvs ci -m"It's little me" junk
RCS file: /tmp/pbw/cvstest/alt.design/junk,v
done
Checking in junk;
/tmp/pbw/cvstest/alt.design/junk,v <-- junk
initial revision: 1.1
done
alt.design 8:06$ cvs log junk

RCS file: /tmp/pbw/cvstest/alt.design/junk,v
Working file: junk
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
THIS FILE IS BEING ADDED.
----------------------------
revision 1.1
date: 2002/11/28 22:05:55; author: pbw; state: Exp;
It's little me
=============================================================================



Another issue to consider is that if you move the files in the repository,
you need to worry about the dependencies in both branches at the same time.
If you move them in your sandbox & check them in, I am pretty sure that you
will need to either 1) only want them moved in one branch (probably not
desirable), or 2) move them twice, once for each branch. Especially on the
maintenance branch, you will want to be careful to get the new files tagged
with the maintenance branch tag.
I don't think anyone here knows all of the implications of hacking the repository. Safety first.

Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to