Re: attic

[Larry Jones]

Ronald Petty writes:
> 
> "If you add a file on a branch, it will have a trunk revision in 'dead'
> state, and a branch revision in a non-dead state."
> 
> Could some one give a clearer meaning to me on this, sorry my brain
> doesn't seem to comprehend this today.

When you add a brand-new file on a branch, CVS creates a revision on the
trunk (1.1) that contains no lines and has a state of "dead" in addition
to the revision on the branch (1.1.2.1) that contains the actual data
and has a state of "Exp" (the normal state).

-Larry Jones

Pitiful.  Just pitiful. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Attic

[Jim.Hyslop]

Gleidson Sá Barreto wrote:
> how do you do to move an arquiv of the Attic to my
> project with TortoiseCVS.
I'm not entirely sure I understand what you're asking. Allow me to explain a
little about the Attic, and see if that answers your question.

When you issue the 'cvs remove' command on a trunk revision of a file, CVS
moves the archive file into the Attic. This happens even if there is a
'live' revision on the branch.

Now, if you are asking how to undo the effects of a 'cvs remove' command,
then simply re-issue the 'cvs add' command, followed by a 'cvs commit'. If
you are asking how to retrieve an older version of the file, then simply use
the -r option to the 'cvs update' command.

Generally, do not be concerned about precisely where in the repository a
file is stored. I like to envision the repository as a warehouse. You and I
should not enter the warehouse, we simply ask the clerk at the counter for
specific files. As long as we get the files we expect, it doesn't matter to
you and me exactly where in the warehouse the file is stored - that's up to
the clerk to manage.

-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. ( http://www.leitch.com )
Columnist, C/C++ Users Journal ( http://www.cuj.com/experts )



___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs

Re: Attic-Directories?

[Larry Jones]

Felix Moedritscher writes:
> 
> I just gzipped some ps-files and replaced them in my repository to save
> space on my harddisk. The problem is, that these ps-files are still in the
> repository and need a lot of space (in a directory called "Attic").
> How can I remove them from there?

You have to do that by hand.  Permanently removing data is anathema to a
revision control system, so there are no CVS commands to do that.

-Larry Jones

How am I supposed to learn surgery if I can't dissect anything? -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Attic Resurrection

[Larry Jones]

Dennis W. Bulgrien writes:
> 
> How can I resurrect a file on which I performed cvs remove and cvs commit?
> I wish I had never done it.



Note that you can use "cvs status file.txt" in your working directory to
get the status of "file.txt" even after its been removed to find out
what the dead revision number is.

-Larry Jones

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

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Attic Resurrection

[gul colak]

Hi,
I also have the same problem, and I wonder copying
content of Attic directory to my directory in CVS
repository works? Or any other way, thanks

--- Larry Jones <[EMAIL PROTECTED]> wrote:
> Dennis W. Bulgrien writes:
> > 
> > How can I resurrect a file on which I performed
> cvs remove and cvs commit?
> > I wish I had never done it.
> 
> 
>

> 
> Note that you can use "cvs status file.txt" in your
> working directory to
> get the status of "file.txt" even after its been
> removed to find out
> what the dead revision number is.
> 
> -Larry Jones
> 
> You should see me when I lose in real life! --
> Calvin
> 
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs


__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Attic Resurrection

[Shubhabrata Sengupta]

Once you find the dead revision with cvs status then all you have to do
is

cvs update -j  -j  file.txt

and then do a cvs commit file.txt

Shubho

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of gul colak
Sent: Thursday, March 28, 2002 11:44 AM
To: Larry Jones; Dennis W. Bulgrien
Cc: [EMAIL PROTECTED]
Subject: Re: Attic Resurrection

Hi,
I also have the same problem, and I wonder copying
content of Attic directory to my directory in CVS
repository works? Or any other way, thanks

--- Larry Jones <[EMAIL PROTECTED]> wrote:
> Dennis W. Bulgrien writes:
> > 
> > How can I resurrect a file on which I performed
> cvs remove and cvs commit?
> > I wish I had never done it.
> 
> 
>
<http://www.cvshome.org/docs/manual/cvs_5.html#SEC62>
> 
> Note that you can use "cvs status file.txt" in your
> working directory to
> get the status of "file.txt" even after its been
> removed to find out
> what the dead revision number is.
> 
> -Larry Jones
> 
> You should see me when I lose in real life! --
> Calvin
> 
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs


__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy AwardsR
http://movies.yahoo.com/

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: attic files

[Kaz Kylheku]

On Tue, 1 Oct 2002, Schwenk, Jeanie wrote:

> How can I retrieve a large quantity of Attic files?  A vendor did a merge
> down the vendor branch and, as it turns out, did a reorganization of some
> files.  The resulting commit moved many, many files in many directories into
> their respective attics.  In the meantime, an engineer here, made changes to
> some of those files that were moved to the attic.  He just came over and
> asked me why "Attic" was in the path to the files he had changes.  We need
> these files (even though the vendors don't) and when a fresh checkout is
> done, we need these files.  If I just get a backup, we'll lose all the
> changes that were made recently.  

Avoiding this sort of disaster is one of the reasons I wrote a program
called Meta-CVS.

In Meta-CVS, if you locally modify a file, and then execute an update
which happens to removes it, that file is not lost. Merely, its name is
removed from the mapping (or unlinked, to borrow a Unix filesystem
term).  What you can do in this situation is execute ``mcvs restore'',
then look for your file in the ``lost+found'' directory off the project
root, where it appears under a cryptic name.  One way to do that is
simply to change to ``lost+found'', then do a ``mcvs diff'' to see
which of the restored files there have local modifications. Use ``mcvs
mv'' to move your files somewhere out of lost+found and reassign
meaningful names to them.  Then ``mcvs rm -R lost+found'' from the root
to send all the remaining restored files back to the realm of the dead.

There is a more permanent way to delete. Executing ``mcvs purge'' will
hunt down unmapped versioned elements and actually do the low-level
``cvs rm'' on them.  This can be done from time to time to reduce
the checkout size of the project.

But, of course, since Meta-CVS handles renames properly, rather than
emulating them with a remove and add, you won't get into this situation
very much at all, except when there occurs a true disagreement between
someone still working on a file, and someone wanting to get rid of it.

The software has a sane vendor import feature in the from of a ``grab''
command.  This function figures out the reorganization performed in
your third-party snapshot. It works with regular branches or the main
trunk, rather than vendor branches, so you can properly track multiple
snapshot sources. 

What would have happened under Meta-CVS is that the vendor's file
movements would simply have been integrated into the grab branch
representing that vendor's code stream.  Then upon merging down from
that branch, the renames would have been propagated to the trunk.

When such structural changes are committed, and users update them,
their local sandbox is rearranged to the new structure, without losing
their local modifications.  If you do some hacking on foo.c and an
update then moves it to src/foo-main.c, then src/foo-main.c still
contains your local modifications that you can review and commit as
usual.

Imagine a picture of the world drawn by a child's hand in colorful
crayons, depicting stick figures holding hands under a yellow sun, in a
garden with giant flowers next to a cute little house. This is
essentially what it's like to use this program. :)



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: attic files

[Schwenk, Jeanie]

Isn't there an easier way to get back all the files, complete with their
history and branches?  I do not want to add a level of indirection to CVS at
this point.  Not all engineers here are used to just-plain-CVS and it's been
installed for over a year.  Changing it on them will generate many visits to
my cube and this is quite simply not in my best interest because I have work
to do.

Jeanie 


-Original Message-
From: Kaz Kylheku [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 01, 2002 5:11 PM
To: Schwenk, Jeanie
Cc: [EMAIL PROTECTED]
Subject: Re: attic files


On Tue, 1 Oct 2002, Schwenk, Jeanie wrote:

> How can I retrieve a large quantity of Attic files?  A vendor did a merge
> down the vendor branch and, as it turns out, did a reorganization of some
> files.  The resulting commit moved many, many files in many directories
into
> their respective attics.  In the meantime, an engineer here, made changes
to
> some of those files that were moved to the attic.  He just came over and
> asked me why "Attic" was in the path to the files he had changes.  We need
> these files (even though the vendors don't) and when a fresh checkout is
> done, we need these files.  If I just get a backup, we'll lose all the
> changes that were made recently.  

Avoiding this sort of disaster is one of the reasons I wrote a program
called Meta-CVS.

In Meta-CVS, if you locally modify a file, and then execute an update
which happens to removes it, that file is not lost. Merely, its name is
removed from the mapping (or unlinked, to borrow a Unix filesystem
term).  What you can do in this situation is execute ``mcvs restore'',
then look for your file in the ``lost+found'' directory off the project
root, where it appears under a cryptic name.  One way to do that is
simply to change to ``lost+found'', then do a ``mcvs diff'' to see
which of the restored files there have local modifications. Use ``mcvs
mv'' to move your files somewhere out of lost+found and reassign
meaningful names to them.  Then ``mcvs rm -R lost+found'' from the root
to send all the remaining restored files back to the realm of the dead.

There is a more permanent way to delete. Executing ``mcvs purge'' will
hunt down unmapped versioned elements and actually do the low-level
``cvs rm'' on them.  This can be done from time to time to reduce
the checkout size of the project.

But, of course, since Meta-CVS handles renames properly, rather than
emulating them with a remove and add, you won't get into this situation
very much at all, except when there occurs a true disagreement between
someone still working on a file, and someone wanting to get rid of it.

The software has a sane vendor import feature in the from of a ``grab''
command.  This function figures out the reorganization performed in
your third-party snapshot. It works with regular branches or the main
trunk, rather than vendor branches, so you can properly track multiple
snapshot sources. 

What would have happened under Meta-CVS is that the vendor's file
movements would simply have been integrated into the grab branch
representing that vendor's code stream.  Then upon merging down from
that branch, the renames would have been propagated to the trunk.

When such structural changes are committed, and users update them,
their local sandbox is rearranged to the new structure, without losing
their local modifications.  If you do some hacking on foo.c and an
update then moves it to src/foo-main.c, then src/foo-main.c still
contains your local modifications that you can review and commit as
usual.

Imagine a picture of the world drawn by a child's hand in colorful
crayons, depicting stick figures holding hands under a yellow sun, in a
garden with giant flowers next to a cute little house. This is
essentially what it's like to use this program. :)


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: attic files

[david]

> How can I retrieve a large quantity of Attic files?  A vendor did a merge
> down the vendor branch and, as it turns out, did a reorganization of some
> files.  The resulting commit moved many, many files in many directories into
> their respective attics.  In the meantime, an engineer here, made changes to
> some of those files that were moved to the attic.  He just came over and
> asked me why "Attic" was in the path to the files he had changes.

So he was working on the RCS-format files in the repository itself?
Didn't he notice anything odd about them?  Misinformed users directly
changing files in the repository will mess up any CVS system, regardless
of whether the files are in the Attic or not.  If anything, you may
be lucky.  If he's changing them now, he may have changed them in the
past, and now you have the opportunity to tell him not to do that
under any circumstances.

So, what exactly did he do?  If he modified a local copy, how did he
check it back in?  (And why would he notice the "Attic" in the path?)

  We need
> these files (even though the vendors don't) and when a fresh checkout is
> done, we need these files.  If I just get a backup, we'll lose all the
> changes that were made recently.  
> 
If you can tell us what the engineer really did, and what changes it
is you'd lose, maybe we can help.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: attic files

[Schwenk, Jeanie]

No, he did not touch the rcs files themselves.   He did that once in the
past.  I believe I made it quite clear that his life would be forfeit if he
did it again.  

When he did a cvs stat of the files, he noted the "Attic" in the path.   He
had the copies of the files before the vendor made his changes.  Now, when
he edits and commits those files, they commit to the Attic.  Although that
seems weird, it does make sense.

Most of the files have multiple branches.  The trunk is code running on the
floor, one is vendor code and one is current development.  Typically the
vendor and development need to be merged into the main trunk for release to
the shop floor.  The vendor inadvertently (due to the import and commit)
removed them because they no longer use these files.  Our development branch
and our main trunk do need these files.  

I've had several suggestions sent to me, just haven't gotten to them yet.
The "just move the file" does not work ... I tried that before I posted.  

Thanks.

Jeanie

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 02, 2002 8:24 AM
To: Schwenk, Jeanie
Cc: CVSpost (E-mail)
Subject: Re: attic files


> How can I retrieve a large quantity of Attic files?  A vendor did a merge
> down the vendor branch and, as it turns out, did a reorganization of some
> files.  The resulting commit moved many, many files in many directories
into
> their respective attics.  In the meantime, an engineer here, made changes
to
> some of those files that were moved to the attic.  He just came over and
> asked me why "Attic" was in the path to the files he had changes.

So he was working on the RCS-format files in the repository itself?
Didn't he notice anything odd about them?  Misinformed users directly
changing files in the repository will mess up any CVS system, regardless
of whether the files are in the Attic or not.  If anything, you may
be lucky.  If he's changing them now, he may have changed them in the
past, and now you have the opportunity to tell him not to do that
under any circumstances.

So, what exactly did he do?  If he modified a local copy, how did he
check it back in?  (And why would he notice the "Attic" in the path?)

  We need
> these files (even though the vendors don't) and when a fresh checkout is
> done, we need these files.  If I just get a backup, we'll lose all the
> changes that were made recently.  
> 
If you can tell us what the engineer really did, and what changes it
is you'd lose, maybe we can help.

-- 
Now building a CVS reference site at http://www.thornleyware.com
[EMAIL PROTECTED]


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: attic files

[Kaz Kylheku]

On Tue, 1 Oct 2002, Schwenk, Jeanie wrote:

> Date: Tue, 1 Oct 2002 17:54:50 -0700
> From: "Schwenk, Jeanie" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [info-cvs] RE: attic files
> 
> Isn't there an easier way to get back all the files, complete with their
> history and branches?

The move to the Attic is a red herring; that is purely an internal
representation that you need not be concerned about. Files in the Attic
are those which have a dead revision on the main trunk (they once
existed on the trunk but have been cvs rm'd or else were added on a
branch and not yet merged to the trunk).

Thanks to Attic, the CVS process has a smaller directory to scan when
checking out or updating the tip of the main trunk; it's not processing
directory entries of these files only to find out they are dead.

Another design choice geared toward making main trunk tip operations
fast is the RCS format itself, which has an explicit representation of
the main trunk head revision. Deltas must be applied to retrieve any
other revision.

What you can do to recover the files is to ``cvs update -D
'' where  specifies a time just before the
vendor branch import happened. This will retrieve the live versions of
your removed files as they existed before the removal.

My solution would be to apply the vendor patch in reverse to undo
the vendor import: cvs update -j : -j :.
Then resolve any conflicts, get the baseline into good
shape again, and migrate to a system that can properly integrate the
restructured third party source tree.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: attic files

[Kaz Kylheku]

"Stefan Monnier <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]> wrote in 
message news:<[EMAIL PROTECTED]>...
> > "Kaz" == Kaz Kylheku <[EMAIL PROTECTED]> writes:
> > Avoiding this sort of disaster is one of the reasons I wrote a program
> > called Meta-CVS.
> 
> OMYGOD 
> This is sooo cool !
> 
> Would it be possible to make it a bit more CVS-friendly ?

Arguably, adding years to the life of CVS is CVS-friendly enough.
There are already enough architectural compromises in the software to
make it easy to integrate with CVS.

> It seems that we could turn a CVS module into a Meta-CVS module by just
> creating a trivial MAP file.  And generally instead of using an `F-12452345'
> filename, Meta-CVS could use the given filename (as long as that filename
> is not already used, of course).  This way people who don't have Meta-CVS
> will still get meaningful names.

Why should anyone do extra work to compromise some freely distributed
software in order to support people who won't actually use it? There
are some very good reasons why versioned elements are named the way
they are. It makes them very easy to recognize and filter in a stream
of text. More importantly, it helps to minimize human confusion when
dealing with two nested levels that are similar to each other. If you
actually use the program for a while, you will see. This was actually
a conscious design decision. I've been happily co-existing with that
decision since January.

> And maybe it could be written in some subset of CL that EmacsLisp can

Emacs Lisp is a hacked down version of a severely obsolete,
dynamically scoped dialect. So far, there is only one person who has
shown programming initiative on this project, and he's not interested
in touching Elisp with a ten foot pole.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: attic files

[Larry Jones]

Schwenk, Jeanie writes:
> 
> How can I retrieve a large quantity of Attic files?  A vendor did a merge
> down the vendor branch and, as it turns out, did a reorganization of some
> files.  The resulting commit moved many, many files in many directories into
> their respective attics.  In the meantime, an engineer here, made changes to
> some of those files that were moved to the attic.  He just came over and
> asked me why "Attic" was in the path to the files he had changes.  We need
> these files (even though the vendors don't) and when a fresh checkout is
> done, we need these files.  If I just get a backup, we'll lose all the
> changes that were made recently.  

If the files have just moved, you probably want to make the changes to
the files in their new locations rather than resurrecting the deleted
files.  But if you're sure you want to resurrect them, just undo the
removal:



-Larry Jones

Who, ME?  Who?! Me??  WHO... Me?!  Who, me??? -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: attic files

[Kaz Kylheku]

"Stefan Monnier <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]> wrote in 
message news:<[EMAIL PROTECTED]>...
> > Arguably, adding years to the life of CVS is CVS-friendly enough.
> > There are already enough architectural compromises in the software to
> > make it easy to integrate with CVS.
> 
> But how about a little script that creates a "MAP" file so you
> can smoothly transition from CVS to Meta-CVS.

I have that script; it's called ``mcvs convert''. That's the one
feature I have not been maintaining, because it doesn't do the right
thing. So it's almost certainly broken right now. It could be made to
work again with a little bit of TLC.

What mcvs convert does is scan through your entire CVS module, and
then create hard links to the ,v files to a bunch of F-...,v files
under a new directory. It then creates a MAP file and calls RCS to
check it in to make a MAP,v.

> After all, people don't want to lose that valuable history when switching.

That's debatable; some people don't care that much. Others are
satisfied to have an archive of the old system. Others still can live
with a few significant snapshots being imported into the new system,
like all their major releases or more fine-grained builds. If you have
that, you can still determine in which build a bug was introduced,
even if you don't have all the commit details between that and the
previous build.

> It should be all that's needed to turn a CVS repository into a Meta-CVS
> one, right ?

No. Doing it right is actually very complicated. You see the CVS
repository has a history, and that history contains file removals,
additions, branches, release tags and so on. To complicate matters,
the fidelity of some the information may be low. Tags may be
inconsistently applied, or appear in different orders in different
files and so on.  The problems is reconstructing a fake history of the
MAP file so that you can actually pull out branches and old releases
as they looked like under CVS, and have the MAP reflect their actual
contents.

With the naive approach, what happens is that the MAP has a single
version node, with an entry for every single object, and all branch
and version tags gathered from the CVS module are pointing at that one
node. When you update yourself to baselines that don't have some of
the files, you get annoying errors, because the MAP tells Meta-CVS to
create structure out of files that aren't there.

The job is to identify all symbolic branches and symbolic releases and
re-create version nodes for them in the MAP,v file.  There is some
primordial
code for doing this, but I haven't touched it in quite a while. Basic
parsing of the RCS file to Lisp data structures, etc.

> And while I'm moaning, I might as well say that I find all those capitals
> unnecessary, whereas I'd love to see a leading "." in those names so
> they don't pollute my listings and completions.

Since you aren't going to be descending into the MCVS directory much,
how the contents look like shouldn't bother you. There is only one
MCVS directory in your whole project, at the root level.

> I wasn't asking you to rewrite it in elisp, but just wondering how
> CLISP- (or just CL-) specific it is.

There is no restriction to any particular subset; any feature of CL
can be used. Presently there is some CLOS, structs, hashes, vectors,
lexical closures, various standard macros, restartable conditions,
etc.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: attic files

[Larry Jones]

Schwenk, Jeanie writes:
> 
> Most of the files have multiple branches.  The trunk is code running on the
> floor, one is vendor code and one is current development.  Typically the
> vendor and development need to be merged into the main trunk for release to
> the shop floor.  The vendor inadvertently (due to the import and commit)
> removed them because they no longer use these files.  Our development branch
> and our main trunk do need these files.  

In that case, merging the branch to the trunk should resurrect the files.

-Larry Jones

It's a Doofus Ignoramus!  Our hero slowly reaches for his stun blaster!
-- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: attic files

[Greg A. Woods]

[ On Wednesday, October 2, 2002 at 12:35:32 (-0700), Schwenk, Jeanie wrote: ]
> Subject: RE: attic files
>
> Most of the files have multiple branches.

How did that happen?  You shouldn't really be trying to use CVS branches
in any module that you created with "cvs import", especially not if the
purpose was to continue maintaining the module as a vendor-branched
project (i.e. do more "cvs import"s).

>  The trunk is code running on the
> floor, one is vendor code and one is current development.  Typically the
> vendor and development need to be merged into the main trunk for release to
> the shop floor.  The vendor inadvertently (due to the import and commit)
> removed them because they no longer use these files.  Our development branch
> and our main trunk do need these files.  

You really don't want to get too fancy with vendor-branched modules.
There are many dark corners.

> I've had several suggestions sent to me, just haven't gotten to them yet.
> The "just move the file" does not work ... I tried that before I posted.  

The proper way to get a file out of the Attic is to "cvs add" it.

-- 
Greg A. Woods

+1 416 218-0098;<[EMAIL PROTECTED]>;   <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: attic files

[Kaz Kylheku]

"Stefan Monnier <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]> wrote in 
message news:<[EMAIL PROTECTED]>...
> > "Kaz" == Kaz Kylheku <[EMAIL PROTECTED]> writes:
> > I have that script; it's called ``mcvs convert''. That's the one
> 
> Sorry, I missed it.

I looked at the source; it's broken. I never updated it to use the new
MAP format since the symlink support was added. It should also pull
out the execute permissions and represent them properly.

> >> It should be all that's needed to turn a CVS repository into a Meta-CVS
> >> one, right ?
> > No. Doing it right is actually very complicated. You see the CVS
> > repository has a history, and that history contains file removals,
> > additions, branches, release tags and so on. To complicate matters,
> > the fidelity of some the information may be low. Tags may be
> > inconsistently applied, or appear in different orders in different
> > files and so on.  The problems is reconstructing a fake history of the
> 
> Yuck.

That's not all; how about reconstructing the renames properly? Suppose
that in the history of the CVS sandbox, someone removed a foo.c, then
added a bar.c with exactly the same contents and kept going. The grab
command can figure this out from snapshots; so the convert command
should do no worse, right?

So you are looking at: taking the contents of foo.c,v and bar.c,v,
determining that they are supposed to be the same object, and then
merging their RCS files into one RCS file, and storing the appropriate
information in the appropriate faked out version nodes of the MAP
file.

> > Since you aren't going to be descending into the MCVS directory much,
> > how the contents look like shouldn't bother you. There is only one
> > MCVS directory in your whole project, at the root level.
> 
> Well, I have many small projects.  I guess I could turn them into
> a single large project, hmmm

You could. Note that Meta-CVS supports the concept of a ``partial
sandbox''. If you type ``mcvs co project sub/dir'' then you get a
sandbox called ``dir'' containing only the specified subdirectory.
This is (currently) not efficient in terms of reducing the amount of
material actually downloaded from CVS, but it gives you the high level
semantics of having checked out just that subdirectory, which can be
useful. As a developer you can pretend that you have a bunch of small
projects. As a release manager, you can treat them as one big project:
branch the whole world at once, tag a release over all the projects,
etc.

If someone renames a file from your visible area into an area of the
project that is not visible in your partial sandbox, or moves files
into your sandbox, this is intelligently handled, and you see messages
like:

   * moving foo.c -> (out of sandbox)
   * moving (out of sandbox) -> bar.html

The grab command supports partial sandboxes also; this allows you to
track third party code at the component level, rather than
whole-project level. For instance if there is some interesting library
you'd like to add as a subdirectory of your project, just add an extra
parameter to grab to specify the subdirectory name. Only that
subdirectory is synchronized to the third-party tree; the invisible
parts of the project are ignored and untouched. If you don't plan on
making any local modifications to it right away, you can just grab
snapshots of it directly to the trunk.

The current Meta-CVS has features that are not described at all in the
Jan. 25 paper, and the format of the MAP file is different too.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Attic files

[Joerg Beyer]

On Wed, Jul 26, 2000 at 01:14:48PM -, Steve Cowling wrote:
> Hello,
> 
> Is it possible to restore files that have accidently been deleted, 
> and placed in the attic back into the main trunck. I have tried just 
> coping the files from the attic back to the original location but 
> WinCVS still cannot see them.

Hi Steve,

have you tried to get them back with something like
cvs checkout -r 1.7 your_file
assuming the last good version was 1.7 or
cvs checkout -D yesterday your_file
assuming you had a good version yesterday ?

hope this helps
Joerg

-- 
This is an air-conditioned system. Do not open Windows!

Re: Attic files

[Larry Jones]

Steve Cowling writes:
> 
> Is it possible to restore files that have accidently been deleted, 
> and placed in the attic back into the main trunck. I have tried just 
> coping the files from the attic back to the original location but 
> WinCVS still cannot see them.

Never screw with the repository directly unless you're absolutely
certain you know what you're doing.  In this case, the correct way to
recover is to do status or log on the file to determine which version it
is that you want to restore (usually it will be the version just prior
to the current "dead" version), use update -p to get a copy of that
version, then add and commit it.

-Larry Jones

My life needs a rewind/erase button. -- Calvin

Re: Attic files

[Lars-Christian Schulze]

On Wed, 26 Jul 2000, Steve Cowling wrote:

> Hello,
> 
> Is it possible to restore files that have accidently been deleted, 
> and placed in the attic back into the main trunck. I have tried just 
> coping the files from the attic back to the original location but 
> WinCVS still cannot see them.
> 
> Cheers for any suggestion
> 
> Steve Cowling
> 

Hello Steve,

this looks to me that you have removed the files from your project via
'cvs remove', right ?  Then it should be possible to simply re-add
them to the project via 'cvs add'.

But I do not know how WinCVS allows access to removed files, because they
are not listed any more in the browser window.  Checking out the latest
revision, as it was suggested by Joerg Beyer in his posting may work.  
But I would suggest to use the -p option in order to avoid stickiness:

   cvs checkout -p -r   your_file  >your_file

Then you should see the file in WinCVS and should be able to re-add it to
the project.

And please do not try to copy or move files within the repository or
modify the files in the CVS subdirectory of your local working directory,
unless you know exactly what you are doing.  CVS can become _very_
confused ...

Greetings
Lars

---
aerodata Flugmesstechnik GmbH  Email   [EMAIL PROTECTED]
Lars-Christian Schulze WWW www.aerodata.de
Hermann-Blenk-Str. 36  Voice   +49 531 2359-188
D-38108 Braunschweig   Fax +49 531 2359-158

Re: Attic files

[Donald Sharp]

Have you tried pulling a new workspace and seeing if 
WinCVS can see them.  The CVS/Entries file is probably
confused now( you can also hand hack them to make them
correct now. )

donald
On Wed, Jul 26, 2000 at 01:14:48PM -, Steve Cowling wrote:
> Hello,
> 
> Is it possible to restore files that have accidently been deleted, 
> and placed in the attic back into the main trunck. I have tried just 
> coping the files from the attic back to the original location but 
> WinCVS still cannot see them.
> 
> Cheers for any suggestion
> 
> Steve Cowling
> 
> 

Re: Attic files

[Mike Castle]

On Wed, Jul 26, 2000 at 10:22:19AM -0400, Larry Jones wrote:
> Never screw with the repository directly unless you're absolutely
> certain you know what you're doing.  In this case, the correct way to
> recover is to do status or log on the file to determine which version it
> is that you want to restore (usually it will be the version just prior
> to the current "dead" version), use update -p to get a copy of that
> version, then add and commit it.

This makes me wonder.

Is that Attic really even necessary?

CVS is doing two things when you delete a file:  Moves it to the attic, and
creates a new version with the state of "dead."

Obviously moving the file isn't enough.   And if one ressurects the file,
I believe it stays in Attic anyway, with a newer state no longer dead.

So, why move a file into the Attic at all?  Just mark them as dead, and
leave it be.   Might simplify code in some parts (of course, wouldn't rip
out all Attic handling, for repositories already using it), but if that
could eventually be pulled too.

What's the saying:  It's done, not when you have no more to add, but when
you have no more feature to remove.

mrc
-- 
   Mike Castle   Life is like a clock:  You can work constantly
  [EMAIL PROTECTED]  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
We are all of us living in the shadow of Manhattan.  -- Watchmen

Re: Attic files

[Larry Jones]

Mike Castle writes:
> 
> Is that Attic really even necessary?

What's your definition of "necessary"?  It makes some things simpler and
other things more difficult.  It's certainly less necessary than it was
before the current death support was added to CVS.

> CVS is doing two things when you delete a file:  Moves it to the attic, and
> creates a new version with the state of "dead."
> 
> Obviously moving the file isn't enough.   And if one ressurects the file,
> I believe it stays in Attic anyway, with a newer state no longer dead.

No, a ressurected file is (supposed to be) moved out of the Attic. 
(There are some bugs that prevent this from happening in some unusual
circumstances.)

> So, why move a file into the Attic at all?  Just mark them as dead, and
> leave it be.   Might simplify code in some parts (of course, wouldn't rip
> out all Attic handling, for repositories already using it), but if that
> could eventually be pulled too.

The idea of moving dead files to the Attic is so that you don't even
have to look at them in most cases.  Not doing it would simplify some
code and complicate other code; whether the net result would be better
or worse, I cannot say.

-Larry Jones

I think your train of thought is a runaway. -- Calvin's Mom

RE: Attic files

[Marquis, Greg E]

I believe the Attic is also used to store files that don't have a version on
the trunk (i.e. a file that was added on a branch).  

Again you could question whether this is strictly necessary, but also again
it could be argued that it makes things easier/more convenient overall.

Also, don't forget how this looks to someone who is responsible for
administration of a repository.  The idea of the Attic provides a nice
conceptual encapsulation for these kinds of circumstances.  Someday, CVS may
be good enough to allow the repository to attain "black box" status, but I
don't think it's there yet.

-Greg

-Original Message-
Mike Castle writes:
> 
> Is that Attic really even necessary?

What's your definition of "necessary"?  It makes some things simpler and
other things more difficult.  It's certainly less necessary than it was
before the current death support was added to CVS.

> CVS is doing two things when you delete a file:  Moves it to 
the attic, and
> creates a new version with the state of "dead."
> 
> Obviously moving the file isn't enough.   And if one 
ressurects the file,
> I believe it stays in Attic anyway, with a newer state no longer dead.

No, a ressurected file is (supposed to be) moved out of the Attic. 
(There are some bugs that prevent this from happening in some unusual
circumstances.)

> So, why move a file into the Attic at all?  Just mark them as 
dead, and
> leave it be.   Might simplify code in some parts (of course, 
wouldn't rip
> out all Attic handling, for repositories already using it), 
but if that
> could eventually be pulled too.

The idea of moving dead files to the Attic is so that you don't even
have to look at them in most cases.  Not doing it would simplify some
code and complicate other code; whether the net result would be better
or worse, I cannot say.

-Larry Jones

I think your train of thought is a runaway. -- Calvin's Mom

Re: Attic files

[Greg A. Woods]

[ On Wednesday, July 26, 2000 at 16:38:31 (-0400), Larry Jones wrote: ]
> Subject: Re: Attic files
>
> The idea of moving dead files to the Attic is so that you don't even
> have to look at them in most cases.  Not doing it would simplify some
> code and complicate other code; whether the net result would be better
> or worse, I cannot say.

For some common operations (eg. "cvs update") the result would be
slower, and in cases where you've got a lot of "dead" files, that would
be "worse".  :-)

I think the Attic is a very necessary optimisation.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  <[EMAIL PROTECTED]>  
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>