CVS Unix to Linux Migration

[Rez]

Hi Everyone

I'm in the midst of migrating our current repository from an old Solaris box to a new Redhat(CentOS 5.2) linux box.

CVS is installed, configured, and all set up on the new server. Users have been re-created and setup in /etc/passwd. I created a test Repo and from a Windows client machine using WinCVS I managed to connect via the pserver method and checkout a project/module successfully.

Could someone please tell me:

1- if the migration is more involved than simply tarballing the repository from the old server and untarring and mounting it on the new server? Meaning, the repository is independent and not affected by the old OS in any way as far as file system or formatting or any other thing go. What else do I need to do on the old server to prepare?

2- Because it's a migration by way of untarring, do I still need to execute "cvs -d /repo/path init" since the existing repo already contains the CVSROOT directory?

3- Also, I would like to get rid of some old projects in the repository before I migrate it, we don't need the history and don't need to save them, so could I just log into the old server as Admin and do an rm or mv command (carefully of course) w/o trashing or corrupting the repository?

Thanks all

Rez
_________________________________________________________________
Windows Live™ Hotmail®:…more than just e-mail.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_explore_012009

[Amaresh Chandra Das]

FYI.....

From: Rez <***@hotmail.com>
Subject: CVS Unix to Linux Migration
To: "CVS" <info-***@nongnu.org>
Date: Wednesday, 4 February, 2009, 11:19 AM

Hi Everyone

I'm in the midst of migrating our current repository from an old Solaris box
to a new Redhat(CentOS 5.2) linux box.

CVS is installed, configured, and all set up on the new server. Users have
been re-created and setup in /etc/passwd. I created a test Repo and from a
Windows client machine using WinCVS I managed to connect via the pserver
method and checkout a project/module successfully.

Could someone please tell me:

1- if the migration is more involved than simply tarballing the repository
from the old server and untarring and mounting it on the new server?
Meaning, the repository is independent and not affected by the old OS in any
way as far as file system or formatting or any other thing go. What else do
I need to do on the old server to prepare?

2- Because it's a migration by way of untarring, do I still need to execute
"cvs -d /repo/path init" since the existing repo already contains the
CVSROOT directory?

*>> You need to do "cvs -d /repo/path init" as we have to synchronize with
init process else it won't work, as init is the Parent process of all
process., **

To synchronize with init process obly we are doing cvs init, else
what is the meant of this command ?
*

3- Also, I would like to get rid of some old projects in the repository
before I migrate it, we don't need the history and don't need to save them,
so could I just log into the old server as Admin and do an rm or mv command
(carefully of course) w/o trashing or corrupting the repository?

Thanks all

Rez

------------------------------
Windows Live™ Hotmail(R):
more than just e-mail. Check it
out.<http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_explore_012009>



Thanks & Regards,

Hare Krishna.....
à€®à€š à€®à¥‡à€°à€Ÿ à€®à€‚à€Šà€¿à€° à€¹à€°à¥€ à€®à¥‡à€°à¥€ à€ªà¥‚à€œà€Ÿ
à€¹à€°à¥€ à€žà¥‡ à€¬à€¡à€Ÿ à€šà€¹à¥€ à€•à¥‹à€ˆ à€Šà¥‚à€œà€Ÿ

Amaresh Chandra Das
Mobile: [phone]
Mail: ***@gmail.com
***@in.com

"Walk with a hope in your heart....you will never walk alone"

[Yves Dorfsman]

Amaresh Chandra Das wrote:
>
> 1- if the migration is more involved than simply tarballing the repository
> from the old server and untarring and mounting it on the new server?
> Meaning, the repository is independent and not affected by the old OS in any
> way as far as file system or formatting or any other thing go. What else do
> I need to do on the old server to prepare?

Yes, although, if you have put your lock directories in a different place,
you will need to create those on the new server. The other catch, is that
often on CVS server, the CVSTMP point somewhere else than the default
(because the default, /tmp, is too small), again you need to make sure that
that directory exists, and that there is enough space in there.

The other thing is, if you use extended ACL, then you need to translate
those between the Solaris ones and the Linux ones.

> 2- Because it's a migration by way of untarring, do I still need to execute
> "cvs -d /repo/path init" since the existing repo already contains the
> CVSROOT directory?

No, when you untar, it will create the CVSROOT directories, which is what
"cvs init" does.


>
> 3- Also, I would like to get rid of some old projects in the repository
> before I migrate it, we don't need the history and don't need to save them,
> so could I just log into the old server as Admin and do an rm or mv command
> (carefully of course) w/o trashing or corrupting the repository?

Are those modules, or repositories ?
If they are repositories, then yes it is easy to delete (mv), if they are
modules, then it is also easy, but it means that your log file will be wrong
which might be an issue if, for example, you transfer to another SCM later.

In either case, disk space is cheap, personally I would archive rather than
delete.

--
Yves.
http://www.sollers.ca/blog/2008/

[Rez]

> Date: Wed, 4 Feb 2009 07:18:17 -0700> From: ***@zioup.com> CC: info-***@nongnu.org> Subject: Re: CVS Unix to Linux Migration> > Amaresh Chandra Das wrote:> > > > 1- if the migration is more involved than simply tarballing the repository> > from the old server and untarring and mounting it on the new server?> > Meaning, the repository is independent and not affected by the old OS in any> > way as far as file system or formatting or any other thing go. What else do> > I need to do on the old server to prepare?> > Yes, although, if you have put your lock directories in a different place, > you will need to create those on the new server. The other catch, is that > often on CVS server, the CVSTMP point somewhere else than the default > (because the default, /tmp, is too small), again you need to make sure that > that directory exists, and that there is enough space in there.

Does cvs by default use the /tmp directory to keep track of locked files? Where's this directive set, in what file, should I tell cvs to direct to another directory, /etc/inetd.conf?> > The other thing is, if you use extended ACL, then you need to translate > those between the Solaris ones and the Linux ones.> > > 2- Because it's a migration by way of untarring, do I still need to execute> > "cvs -d /repo/path init" since the existing repo already contains the> > CVSROOT directory?> > No, when you untar, it will create the CVSROOT directories, which is what > "cvs init" does.> > > > > > 3- Also, I would like to get rid of some old projects in the repository> > before I migrate it, we don't need the history and don't need to save them,> > so could I just log into the old server as Admin and do an rm or mv command> > (carefully of course) w/o trashing or corrupting the repository?> > Are those modules, or repositories ?> If they are repositories, then yes it is easy to delete (mv), if they are > modules, then it is also easy, but it means that your log file will be wrong > which might be an issue if, for example, you transfer to another SCM later.

They're not respositories but projects under it. So then does that mean I have to use a cvs client to remove them and commit them to the attic? Thanks for your help.
> > In either case, disk space is cheap, personally I would archive rather than > delete.> > -- > Yves.> http://www.sollers.ca/blog/2008/> > >
_________________________________________________________________
Windows Live™: Keep your life in sync.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_022009

[Todd Denniston]

Rez wrote, On 02/04/2009 12:49 AM:
> Hi Everyone
>
> I'm in the midst of migrating our current repository
> from an old Solaris box
> to a new Redhat(CentOS 5.2) linux box.
>
> CVS is installed, configured, and all set up on the new server.
> Users have been re-created and setup in /etc/passwd.
> I created a test Repo and from a Windows client machine
> using WinCVS I managed to connect via the
> pserver method and checkout a project/module successfully.

I assume this means you have modified the /etc/xinet.d/cvs file correctly and
thus inet recognizes calls to it on 2401.

>
> Could someone please tell me:
>
> 1- if the migration is more involved than simply tarballing
> the repository from the old server and untarring and
> mounting it on the new server?
> Meaning, the repository is independent and not affected
> by the old OS in any way as far as file system or
> formatting or any other thing go.

The file structure should be good.
The permissions/ownership may need to be tweaked if all the names/UID/GID of
the users do not match from system to system.

> What else do I need to do on the old server to prepare?
On the old server, I would disable cvs in /etc/inet or /etc/network/inet
(where ever the Solaris you are working with hid it's inetd config) and
restart inetd... BEFORE making the final tarball to put on the new machine.
Reason: you don't want to loose any changes someone makes while you are
turning on the new machine.

>
> 2- Because it's a migration by way of untarring,
> do I still need to execute "cvs -d /repo/path init"
> since the existing repo already contains the CVSROOT directory?

It is still a good idea, because by doing that cvs will create, with default
settings, any new config files that did not exist when the old cvs was made.

>
> 3- Also, I would like to get rid of some old projects
> in the repository before I migrate it, we don't need
> the history and don't need to save them,
> so could I just log into the old server as Admin and
> do an rm or mv command (carefully of course) w/o
> trashing or corrupting the repository?

rm or mv in the repo is by definition "corrupting the repository". :)
I would on the new server, build a script that did appropriate rm's based on
where you are putting the final repo and what you know needs to go away, then
when you untar the last tarball, run the script on the new repository.
This way, if you quickly figure out you made a mistake, you still have
everything as it was on the old server.
Summary: keep the old server as it was, so it is a back up to the backup. :)

>
> Thanks all
>
> Rez

--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter

[Rez]

> Date: Wed, 4 Feb 2009 09:58:47 -0500> From: ***@ssa.crane.navy.mil> To: ***@hotmail.com> CC: info-***@nongnu.org> Subject: Re: CVS Unix to Linux Migration> > Rez wrote, On 02/04/2009 12:49 AM:> > Hi Everyone> > > > I'm in the midst of migrating our current repository > > from an old Solaris box > > to a new Redhat(CentOS 5.2) linux box.> > > > CVS is installed, configured, and all set up on the new server. > > Users have been re-created and setup in /etc/passwd. > > I created a test Repo and from a Windows client machine > > using WinCVS I managed to connect via the > > pserver method and checkout a project/module successfully.> > I assume this means you have modified the /etc/xinet.d/cvs file correctly and > thus inet recognizes calls to it on 2401.

Yes, I can both telnet to the port and connect via a cvs client to the server. Would you please check the content of my file to make sure it's ok, thanks:

$ cat /etc/xinetd.d/cvs# default: off# description: The CVS service can record the history of your source \# files. CVS stores all the versions of a file in a single \# file in a clever way that only stores the differences \# between versions.service cvspserver{ disable = no port = 2401 socket_type = stream protocol = tcp wait = no user = root passenv = PATH server = /usr/bin/cvs env = HOME=/cvs server_args = -f --allow-root=/cvs pserver# bind = 127.0.0.1}
2 questions:

1. is cvs is a reserved word or could I or should I call a repository cvs or can it be part of a path /repo/cvs/proj?
2. in server_args, is the placement of the -f parameter ok?
> > > > > Could someone please tell me:> > > > 1- if the migration is more involved than simply tarballing > > the repository from the old server and untarring and > > mounting it on the new server? > > Meaning, the repository is independent and not affected > > by the old OS in any way as far as file system or > > formatting or any other thing go. > > The file structure should be good.> The permissions/ownership may need to be tweaked if all the names/UID/GID of > the users do not match from system to system.> > > What else do I need to do on the old server to prepare?> On the old server, I would disable cvs in /etc/inet or /etc/network/inet > (where ever the Solaris you are working with hid it's inetd config) and > restart inetd... BEFORE making the final tarball to put on the new machine.> Reason: you don't want to loose any changes someone makes while you are > turning on the new machine.

Good point, thanks.
> > > > > 2- Because it's a migration by way of untarring, > > do I still need to execute "cvs -d /repo/path init" > > since the existing repo already contains the CVSROOT directory? > > It is still a good idea, because by doing that cvs will create, with default > settings, any new config files that did not exist when the old cvs was made.

Will do, thanks.
> > > > > 3- Also, I would like to get rid of some old projects > > in the repository before I migrate it, we don't need > > the history and don't need to save them, > > so could I just log into the old server as Admin and > > do an rm or mv command (carefully of course) w/o > > trashing or corrupting the repository?> > rm or mv in the repo is by definition "corrupting the repository". :)> I would on the new server, build a script that did appropriate rm's based on > where you are putting the final repo and what you know needs to go away, then > when you untar the last tarball, run the script on the new repository.> This way, if you quickly figure out you made a mistake, you still have > everything as it was on the old server.> Summary: keep the old server as it was, so it is a back up to the backup. :)> > > > > Thanks all> > > > Rez> > -- > Todd Denniston> Crane Division, Naval Surface Warfare Center (NSWC Crane)> Harnessing the Power of Technology for the Warfighter
_________________________________________________________________
Windows Live™: E-mail. Chat. Share. Get more ways to connect.
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_022009

[Todd Denniston]

Rez wrote, On 02/04/2009 05:35 PM:
>> Date: Wed, 4 Feb 2009 09:58:47 -0500> From: ***@ssa.crane.navy.mil> To: ***@hotmail.com> CC: info-***@nongnu.org> Subject: Re: CVS Unix to Linux Migration> > Rez wrote, On 02/04/2009 12:49 AM:> > Hi Everyone> > > > I'm in the midst of migrating our current repository > > from an old Solaris box > > to a new Redhat(CentOS 5.2) linux box.> > > > CVS is installed, configured, and all set up on the new server. > > Users have been re-created and setup in /etc/passwd. > > I created a test Repo and from a Windows client machine > > using WinCVS I managed to connect via the > > pserver method and checkout a project/module successfully.> > I assume this means you have modified the /etc/xinet.d/cvs file correctly and > thus inet recognizes calls to it on 2401.
>
> Yes, I can both telnet to the port and connect via a cvs client to the server. Would you please check the content of my file to make sure it's ok, thanks:
>
> $ cat /etc/xinetd.d/cvs# default: off# description: The CVS service can rec=
ord the history of your source \# files. CVS stores all the ve=
rsions of a file in a single \# file in a clever way that only=
stores the differences \# between versions.service cvspserver=
{ disable =3D no port =3D 2401 sock=
et_type =3D stream protocol =3D tcp =
wait =3D no user =3D root =
passenv =3D PATH server =3D /u=
sr/bin/cvs env =3D HOME=3D/cvs server_arg=
s =3D -f --allow-root=3D/cvs pserver# bind =
=3D 127.0.0.1}

Res, can you see if hotmail will let you turn off "quoted-printable" & HTML &
RTF, and thus let you send plain text?

http://www.catb.org/~esr/faqs/smart-questions.html#formats
http://www.expita.com/nomime.html#programs
http://www.expita.com/nomime.html#hotmail

I find your replies difficult to interpret to the point I usually only reply
to your original posts (which for some reason are readable).

Thanks.
--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter

[Rez]

Thanks. I will double check my hotmail settings.

> Date: Thu, 5 Feb 2009 08:58:57 -0500> From: ***@ssa.crane.navy.mil> To: ***@hotmail.com> CC: info-***@nongnu.org> Subject: Re: CVS Unix to Linux Migration> > Rez wrote, On 02/04/2009 05:35 PM:> >> Date: Wed, 4 Feb 2009 09:58:47 -0500> From: ***@ssa.crane.navy.mil> To: ***@hotmail.com> CC: info-***@nongnu.org> Subject: Re: CVS Unix to Linux Migration> > Rez wrote, On 02/04/2009 12:49 AM:> > Hi Everyone> > > > I'm in the midst of migrating our current repository > > from an old Solaris box > > to a new Redhat(CentOS 5.2) linux box.> > > > CVS is installed, configured, and all set up on the new server. > > Users have been re-created and setup in /etc/passwd. > > I created a test Repo and from a Windows client machine > > using WinCVS I managed to connect via the > > pserver method and checkout a project/module successfully.> > I assume this means you have modified the /etc/xinet.d/cvs file correctly and > thus inet recognizes calls to it on 2401.> > > > Yes, I can both telnet to the port and connect via a cvs client to the server. Would you please check the content of my file to make sure it's ok, thanks:> > > > $ cat /etc/xinetd.d/cvs# default: off# description: The CVS service can rec=> ord the history of your source \# files. CVS stores all the ve=> rsions of a file in a single \# file in a clever way that only=> stores the differences \# between versions.service cvspserver=> { disable =3D no port =3D 2401 sock=> et_type =3D stream protocol =3D tcp => wait =3D no user =3D root => passenv =3D PATH server =3D /u=> sr/bin/cvs env =3D HOME=3D/cvs server_arg=> s =3D -f --allow-root=3D/cvs pserver# bind => =3D 127.0.0.1}> > Res, can you see if hotmail will let you turn off "quoted-printable" & HTML & > RTF, and thus let you send plain text?> > http://www.catb.org/~esr/faqs/smart-questions.html#formats> http://www.expita.com/nomime.html#programs> http://www.expita.com/nomime.html#hotmail> > I find your replies difficult to interpret to the point I usually only reply > to your original posts (which for some reason are readable).> > Thanks.> -- > Todd Denniston> Crane Division, Naval Surface Warfare Center (NSWC Crane)> Harnessing the Power of Technology for the Warfighter
_________________________________________________________________
Windows Live™: Keep your life in sync.
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_022009

[Larry Jones]

Rez writes:
>
> 1- if the migration is more involved than simply tarballing the
> repository from the old server and untarring and mounting it on the new
> server?

Nope, that's all you need to do.

> 2- Because it's a migration by way of untarring, do I still need to
> execute "cvs -d /repo/path init" since the existing repo already
> contains the CVSROOT directory?

You don't have to, but it won't hurt and it's a good idea.
Particularly if the new server is running a newer release of CVS than
the old server was.

> 3- Also, I would like to get rid of some old projects in the
> repository before I migrate it, we don't need the history and don't need
> to save them, so could I just log into the old server as Admin and do an
> rm or mv command (carefully of course) w/o trashing or corrupting the
> repository?

Yep.
--
Larry Jones

The problem with the future is that it keeps turning into the present.
-- Hobbes

[Spiro Trikaliotis]

Hello,

* On Wed, Feb 04, 2009 at 10:18:16AM -0500 Larry Jones wrote:

> > 2- Because it's a migration by way of untarring, do I still need to
> > execute "cvs -d /repo/path init" since the existing repo already
> > contains the CVSROOT directory?
>
> You don't have to, but it won't hurt and it's a good idea.
> Particularly if the new server is running a newer release of CVS than
> the old server was.

(perhaps it is obvious to everyone, but it seems I understood the
question different to the others, thus, I want to add to the OP:)

Execute the "cvs -d ... init" *after* you have untarred the repo on the
new machine, not before. Then, this command will update the CVSROOT to
the "newer format" (so to speak). Do not execute this command before
untarring the repo.

Best regards,
Spiro.

--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/

[Rez]

> Date: Wed, 4 Feb 2009 22:36:47 +0100> From: list-info-***@spiro.trikaliotis.net> To: info-***@nongnu.org> Subject: Re: CVS Unix to Linux Migration> > Hello,> > * On Wed, Feb 04, 2009 at 10:18:16AM -0500 Larry Jones wrote:> > > > 2- Because it's a migration by way of untarring, do I still need to> > > execute "cvs -d /repo/path init" since the existing repo already> > > contains the CVSROOT directory? > > > > You don't have to, but it won't hurt and it's a good idea. > > Particularly if the new server is running a newer release of CVS than> > the old server was.> > (perhaps it is obvious to everyone, but it seems I understood the> question different to the others, thus, I want to add to the OP:)> > Execute the "cvs -d ... init" *after* you have untarred the repo on the> new machine, not before. Then, this command will update the CVSROOT to> the "newer format" (so to speak). Do not execute this command before> untarring the repo.>

Thanks for your feedback. I'm still in the testing phase and ran it before but when going live, I will do it after. Thanks.

> Best regards,> Spiro.> > -- > Spiro R. Trikaliotis http://opencbm.sf.net/> http://www.trikaliotis.net/ http://www.viceteam.org/> >
_________________________________________________________________
Windows Live™: E-mail. Chat. Share. Get more ways to connect.
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_022009

[Rez]

> Subject: Re: CVS Unix to Linux Migration> To: ***@hotmail.com> Date: Wed, 4 Feb 2009 10:18:16 -0500> CC: info-***@nongnu.org> From: ***@siemens.com> > Rez writes:> > > > 1- if the migration is more involved than simply tarballing the> > repository from the old server and untarring and mounting it on the new> > server?> > Nope, that's all you need to do.> > > 2- Because it's a migration by way of untarring, do I still need to> > execute "cvs -d /repo/path init" since the existing repo already> > contains the CVSROOT directory? > > You don't have to, but it won't hurt and it's a good idea. > Particularly if the new server is running a newer release of CVS than> the old server was.

Good think I asked. It's a newer version, so I will run it just in case. Thanks.
> > > 3- Also, I would like to get rid of some old projects in the> > repository before I migrate it, we don't need the history and don't need> > to save them, so could I just log into the old server as Admin and do an> > rm or mv command (carefully of course) w/o trashing or corrupting the> > repository?> > Yep.

Yves, mentioned that I may corrupt my cvs log or rather render it useless by doing file system commands (mv, rm) if they're projects within the repository. I don't see a log anywhere. Where's the log and could I modify it manually?

Thanks for all your help.> -- > Larry Jones> > The problem with the future is that it keeps turning into the present.> -- Hobbes
_________________________________________________________________
Windows Live™: E-mail. Chat. Share. Get more ways to connect.
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_022009

[Larry Jones]

Rez writes:
>
> Does cvs by default use the /tmp directory to keep track of locked files?

No. By default, it puts the lock files in the repository with the RCS
files.

> Where's this directive set, in what file, should I tell cvs to direct
> to another directory, /etc/inetd.conf?

Which directive? The lock file location can be set with the LockDir=
keyword in the $CVSROOT/CVSROOT/config file. The temp file directory
can be set by adding the -T option to the server command options in
[x]inetd.conf or by setting $TMPDIR in the server's environment.
--
Larry Jones

I wonder if I can grow fangs when my baby teeth fall out. -- Calvin

[Rez]

Ok that's what I needed to know. Thanks for all your help.> Subject: Re: CVS Unix to Linux Migration> To: ***@hotmail.com> Date: Thu, 5 Feb 2009 11:38:17 -0500> CC: ***@zioup.com; info-***@nongnu.org> From: ***@siemens.com> > Rez writes:> > > > Does cvs by default use the /tmp directory to keep track of locked files?> > No. By default, it puts the lock files in the repository with the RCS> files.> > > Where's this directive set, in what file, should I tell cvs to direct> > to another directory, /etc/inetd.conf?> > Which directive? The lock file location can be set with the LockDir=> keyword in the $CVSROOT/CVSROOT/config file. The temp file directory> can be set by adding the -T option to the server command options in> [x]inetd.conf or by setting $TMPDIR in the server's environment.> -- > Larry Jones> > I wonder if I can grow fangs when my baby teeth fall out. -- Calvin
_________________________________________________________________
Windows Live™: E-mail. Chat. Share. Get more ways to connect.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_allup_explore_022009

[Larry Jones]

Rez writes:
>
> Yves, mentioned that I may corrupt my cvs log or rather render it
> useless by doing file system commands (mv, rm) if they're projects
> within the repository. I don't see a log anywhere. Where's the log and
> could I modify it manually?

I have no idea what he was taking about, perhaps he can explain further.
--
Larry Jones

Don't you hate it when your boogers freeze? -- Calvin

[Rez]

In my original email I had asked the question:

In our singular repository we have a few obsolote projects or folders, we don't need them, and we don't need the history either. Should I login to the repository server and delete the obsolete folders directly from the file system or via my Windows client, check them out, delete and commit them to the attic. Yves had suggested the latter, mentioning that the latter method will keep the integrity of the cvs log in check.

My problem with this latter method is that all the files in the attic still occupy space and mind you, these are projects we don't need anymore. What do you recommend?

Thanks

Res


> Subject: Re: CVS Unix to Linux Migration> To: ***@hotmail.com> Date: Thu, 5 Feb 2009 11:39:41 -0500> CC: info-***@nongnu.org> From: ***@siemens.com> > Rez writes:> > > > Yves, mentioned that I may corrupt my cvs log or rather render it> > useless by doing file system commands (mv, rm) if they're projects> > within the repository. I don't see a log anywhere. Where's the log and> > could I modify it manually?> > I have no idea what he was taking about, perhaps he can explain further. > -- > Larry Jones> > Don't you hate it when your boogers freeze? -- Calvin
_________________________________________________________________
Windows Live™: E-mail. Chat. Share. Get more ways to connect.
http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_AE_Faster_022009

[Larry Jones]

Rez writes:
>
> My problem with this latter method is that all the files in the attic
> still occupy space and mind you, these are projects we don't need
> anymore. What do you recommend?

Disk space is cheap -- if there's *any* chance you might want to
resurrect any of those project in the future, I recommend leaving them
just as they are and ignoring them. (There really isn't any value in
"cvs remove"ing an entire project just to move the RCS files into the
Attic, just don't check those projects out any more.) That said, if
you're really sure you won't ever need them again and you really need
the disk space, there's no harm in just deleting the RCS files (and
directories) from the repository.
--
Larry Jones

You should see me when I lose in real life! -- Calvin

[Rez]

Thank you for all the info and your help.> Subject: Re: CVS Unix to Linux Migration> To: ***@hotmail.com> Date: Thu, 5 Feb 2009 22:22:22 -0500> CC: info-***@nongnu.org> From: ***@siemens.com> > Rez writes:> > > > My problem with this latter method is that all the files in the attic> > still occupy space and mind you, these are projects we don't need> > anymore. What do you recommend?> > Disk space is cheap -- if there's *any* chance you might want to> resurrect any of those project in the future, I recommend leaving them> just as they are and ignoring them. (There really isn't any value in> "cvs remove"ing an entire project just to move the RCS files into the> Attic, just don't check those projects out any more.) That said, if> you're really sure you won't ever need them again and you really need> the disk space, there's no harm in just deleting the RCS files (and> directories) from the repository.> -- > Larry Jones> > You should see me when I lose in real life! -- Calvin
_________________________________________________________________
Windows Live™: Keep your life in sync.
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_022009