Re: Getting a file that was removed in repository back?

[Larry Jones]

Albin Takami writes:
> 
> Now in your book (Open Source Development With CVS chapter: What Happens
> When You Remove A File), you mention that "This means that if you want to
> restore a removed file, you can't just take it out of the Attic/ and put it
> back into the project. Instead, you have to do something like this in a
> working copy"
> If I don't have a working copy, meaning I don't have a checked out copy of
> that file, how do I then get it back/restored?

You don't need a checked out copy of the *file*, you need a checked out
copy of the *directory* that contains (or used to contain) it.  See the
end of: .

-Larry Jones

Hmph. -- Calvin


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

RE: Getting a file that was removed in repository back?

[Albin Takami]

Hi Karl and all,

If I removed files using cvs (cvs rm), I see the files I removed in the
Attic-dir.
Now in your book (Open Source Development With CVS chapter: What Happens
When You Remove A File), you mention that "This means that if you want to
restore a removed file, you can't just take it out of the Attic/ and put it
back into the project. Instead, you have to do something like this in a
working copy"
If I don't have a working copy, meaning I don't have a checked out copy of
that file, how do I then get it back/restored?

Best regards,
Albin


 -Original Message-
From:   Karl Fogel [mailto:[EMAIL PROTECTED]]  On Behalf Of Karl
Fogel
Sent:   Wednesday, August 07, 2002 6:34 PM
To: [EMAIL PROTECTED]
Subject:Re: Getting a file that was removed in repository back?

"Albin Takami" <[EMAIL PROTECTED]> writes:
> So, I was wondering how I can get the testing123.v file back, after
removing
> it in the repository?

You can't get it back.  You've removed it.  It's gone.

The only thing you can do now is remove any references from it in your
working copies (delete the appropriate line in CVS/Entries files in
working copies).

There is no typo, you just have to read the commands in the example
carefully.  Line 3 is an "ls", not a "cd", in particular.

-Karl

> ..
> ..
> What Happens When You Remove A File
> When you remove a file from a project, it doesn't just disappear. CVS must
> be able to retrieve such files when you request an old snapshot of the
> project. Instead, the file gets put in the Attic, literally:
>
> 1. floss$ pwd
> 2. /home/jrandom/src/myproj
> 3. floss$ ls /usr/local/newrepos/myproj/
> 4. README.txt,v  a-subdir/ b-subdir/ foo.jpg,v   hello.c,v
> 5. floss$ rm foo.jpg
> 6. floss$ cvs rm foo.jpg
> 7. cvs remove: scheduling 'foo.jpg' for removal
> 8. cvs remove: use 'cvs commit' to remove this file permanently
> 9. floss$ cvs ci -m "Removed foo.jpg" foo.jpg
> 10. Removing foo.jpg;
> 11. /usr/local/newrepos/myproj/foo.jpg,v  <--  foo.jpg
> 12. new revision: delete; previous revision: 1.1
> 13. done
> 
> ...
> ..
>
> Hope you can help.
>
> Best regards,
> Albin



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

Re: Getting diffs between two revisions

[Larry Jones]

Mike Ayers writes:
> 
>   If I am interpreting correctly, no such tags were made.  Johnny wants 
> to "get changes between July 17 and July 19 placed into my local 
> working copy", i.e.  filter based solely on date of commit, which I do 
> not believe is possible with CVS.

Derek was suggesting that he could add such tags now (using dates) and
then use those tags to get the desired results.

-Larry Jones

Bad news, Mom.  I promised my soul to the Devil this afternoon. -- Calvin


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

Re: Getting diffs between two revisions

[Derek Robert Price]

Mike Ayers wrote:

>
>
> Derek Robert Price wrote:
>
>> In other words, it's a static tag, the most recent version on the 
>> trunk, not the trunk itself as a branch.  There isn't a trunk tag, 
>> but if you use dates to tag the trunk at the two times you mentioned, 
>> you should be able to get what you were trying to.
>
>
> If I am interpreting correctly, no such tags were made.  Johnny 
> wants to "get changes between July 17 and July 19 placed into my local 
> working copy", i.e.  filter based solely on date of commit, which I do 
> not believe is possible with CVS.


No, but you can tag based solely on the date of the commit.  So he could 
tag twice and then use those to get the information he wanted.  Silly, I 
know, but if you'd like to fix it and submit the patch, I'll check it in.

It'd be nice to see every -r capable of accepting the tag:date format 
too, but that's another issue entirely.

Derek

-- 
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at http://ximbiot.com





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

Re: Getting diffs between two revisions

[Mike Ayers]

Derek Robert Price wrote:
> Johnny John wrote:
> 
>> Hello:
>>
>> Should I not be able to update my working copy of a file by doing 
>> something as follows?
>>
>> cvs update -j HEAD:"2002-07-17 12:00" -j HEAD:"2002-07-19 12:00"
>>
>> to get changes between July 17 and July 19 placed into my local 
>> working copy?
>>
>> I tried it, and nothing was patched.
>>
>> thanks.
>> -Johnny.
> 
> 
> 
>  From :
> 
>  > `HEAD' refers to the most recent version available in the repository
> 
> In other words, it's a static tag, the most recent version on the trunk, 
> not the trunk itself as a branch.  There isn't a trunk tag, but if you 
> use dates to tag the trunk at the two times you mentioned, you should be 
> able to get what you were trying to.

If I am interpreting correctly, no such tags were made.  Johnny wants 
to "get changes between July 17 and July 19 placed into my local 
working copy", i.e.  filter based solely on date of commit, which I do 
not believe is possible with CVS.


/|/|ike




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

Re: CVS corruption

[Rob Helmer]

Hello,


Well, I don't think "salvaging by hand" would be good or neccessarily effective :)
Or easy, for that matter.

For one, depends on the corruption, if it's a hardware or kernel VFS failure
of some kind, and the blocks that the file are on are bad, then there is no
salvaging it, since the data itself will be gone.

If you are lucky, maybe you can pull out the original version, even luckier
if you can get a diff to a newer version. That is unlikely, though.

If some bug in CVS for example screws up the format of the RCS file, you
might be able to save it in this way, but it's not a sure thing. It really
depends on the situation.

As with any data you deem important, make regular backups, and verify your
backups. It's alot easier to restore from backup than it is to go around
manually editing RCS files :)



HTH,
Rob Helmer
Namodn


On Fri, Aug 16, 2002 at 10:47:29AM +1000, Tehn Yit Chin wrote:
> Thanks for the info. I did mean the CVS binary corrupting.
> 
> It is good the hear that the file can be salvage by hand if required. Would
> it be just as easy if the file is a binary?
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Rob Helmer
> Sent: Friday, August 16, 2002 10:36 AM
> To: [EMAIL PROTECTED]
> Subject: Re: CVS corruption
> 
> 
> Hello,
> 
> 
> Well, if files in the repository are corrupted, it will not help to
> reinstall CVS. You'll need to try to salvage them somehow, or restore
> them from backup.
> 
> If you mean the CVS binary or installation is somehow corrupted, remember
> that every file in the repository is an RCS file, so you can access the
> file with RCS as well as CVS ( you could even put a file together
> by hand if you wanted, the format isn't difficult to parse ).
> 
> 
> 
> HTH,
> Rob Helmer
> 
> 
> On Fri, Aug 16, 2002 at 08:45:12AM +1000, Tehn Yit Chin wrote:
> > Hi all,
> >
> > If CVS gets corrupted, can the files in the repository be accessed without
> > reinstalling CVS?
> >
> > thanks,
> > Tehn Yit Chin
> >
> > 
> > Tehn Yit Chin   mb: +61 418 139 181
> > MILLISON TECHNOLOGY Pty. Ltd.   ph: +61 3 8793 9500
> > Electronics Design Services fx: +61 3 9798 7633
> > http://www.millison.com.au  mailto:[EMAIL PROTECTED]
> > 
> >
> >
> >
> > ___
> > 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
> 
> 
> 
> ___
> 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: Getting diffs between two revisions

[Derek Robert Price]

Johnny John wrote:

> Hello:
>
> Should I not be able to update my working copy of a file by doing 
> something as follows?
>
> cvs update -j HEAD:"2002-07-17 12:00" -j HEAD:"2002-07-19 12:00"
>
> to get changes between July 17 and July 19 placed into my local 
> working copy?
>
> I tried it, and nothing was patched.
>
> thanks.
> -Johnny.


 From :

 > `HEAD' refers to the most recent version available in the repository

In other words, it's a static tag, the most recent version on the trunk, 
not the trunk itself as a branch.  There isn't a trunk tag, but if you 
use dates to tag the trunk at the two times you mentioned, you should be 
able to get what you were trying to.

Derek

-- 
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at http://ximbiot.com
-- 
105. I don't suffer from insanity. I enjoy every minute of it. 





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

Re: Help with tags

[Derek Robert Price]

Larry Jones wrote:

>Mullican, Catherine writes:
>  
>
>>All the files included in our 4.4.1.0 release are tagged v4_4_1_0 at the
>>appropriate revision.
>>Files modified since that time which should be included in the 4.4.1.1
>>release are tagged v4_4_1_1 -- but only changed files are currently tagged.
>>
>>
>
>That's the problem -- you need to tag *all* the files.  You can tag as
>you go by specifying -F to tag to allow it to move the existing tag, but
>you'll have to be careful that you don't move the wrong tag by accident.
>Better is to wait until you're ready to release 4.4.1.1 to tag all the
>files.  If you want to change files that aren't supposed to go into the
>4.1.1.1 release, you should either make those changes on a branch or
>else make a branch for the 4.1.1.1 release.
>  
>

Larry neglected to mention that, assuming the `cvs up -rv4_4_1_0' 
command he _did_ mention works, `cvs up -r v4_4_1_0 -jv4_4_1_0 
-jv4_4_1_1' should get you your 4.4.1.1 release as well, though I agree 
that just tagging the whole thing would be easier.  You should be able 
to retroactively `cvs up -rv4_4_1_0; cvs tag v4_4_1_1' safely since 
_without_ `-F', tag won't overwrite existing tags.  Then `cvs up 
-rv4_4_1_1' should get you your 4.4.1.1 release.

>>And to make matters worse, we can't seem to go back to 4.4.1.0 anymore, even
>>after a cvs up -A.  All the files are still being removed from the working
>>directory.  They look OK in CVS via the web interface.
>>
>>
>
>   cvs up -r v4_4_1_0
>  
>

Derek

-- 
*8^)

Email: [EMAIL PROTECTED]

Get CVS support at http://ximbiot.com
-- 
I am for encouraging the progress of science in all its branches, and not for
raising a hue and cry against the sacred name of philosophy; for awing the
human mind by stories of raw-head and bloody bones to a distrust of its own
vision, and to repose implicitly on that of others; to go backwards instead of
forwards to look for improvement; to believe that government, religion,
morality and every other science were in the highest perfection in the ages of
the darkest ignorance, and that nothing can ever be decided more perfect than
what was established by our forefathers.

- Thomas Jefferson to Elbridge Gerry, 1799





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

How can I statically link CVS on Solaris 8?

[Neis, Mark]

Hi !

First, let me say that I'm fairly new to this, so bear with me should I make
stupid
assumptions. 

I'm trying to get a statically linked CVS binary on a Sparc/Solaris 8 box in
order to set
up a chrooted environment. 

So I first compiled the sources with the regular Makefile, logged the
compiler's output
to a file and then re-used the line that starts the linking process and
inserted '-static':

|  gcc -static add.o admin.o buffer.o checkin.o checkout.o classify.o
client.o commit.o
|  [...lots of object files...]
|  error.o zlib.o ../lib/libcvs.a ../zlib/libz.a ../diff/libdiff.a -lxnet
-o cvs

This is the way Pascal J. Bourguignon handles things in his 'Chrooted SSH
CVS
Management scripts' [1] (based on those from idealx.org). Apparently, it
works
this way on SuSE Linux. 

Unfortunately, Solaris keeps telling me that -lxnet was missing:
|  ld: fatal: library -lxnet: not found
|  ld: fatal: File processing errors. No output written to cvs
|  collect2: ld returned 1 exit status

So had a second go and tried to add the options to the Makefile in the src
directory:
|  LDFLAGS = -Xlinker -static

The output then looks as follows:
|  gcc add.o admin.o buffer.o checkin.o checkout.o classify.o client.o
commit.o
|  [... lots of object files...]
|  ../lib/libcvs.a ../zlib/libz.a ../diff/libdiff.a -lxnet  -Xlinker -static
-o cvs
|  ld: fatal: option -dy and -a are incompatible
|  ld: fatal: Flags processing errors
|  collect2: ld returned 1 exit status
|  make: *** [cvs] Error 1

Conflicting options, telling the linker to link dynamically <-> statically?
Well, there is no -dy option in the Makefile. Is this implicitly set
somewhere ?
I guess I'm stuck here. I'd kindly appreciate any hints and help. 

If you feel that this ML is the wrong place to deal with this question, it
would
be nice if you could tell me a more suitable forum. 

Mark Neis

[1] http://informatimago.free.fr/i/linux/chrooted-ssh-cvs.en.html




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