info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with partially lost branch information


From: Eric Siegerman
Subject: Re: Problem with partially lost branch information
Date: Mon, 25 Nov 2002 13:34:06 -0500
User-agent: Mutt/1.2.5i

On Mon, Nov 25, 2002 at 02:05:00PM +0100, Karl-König Königsson wrote:
> [...] a file with the branch tag set should have a 
> cvs version number with a zero in it; one of the adminstrative numbers. 
> I thus did this from the command line:
> 
>     find . -type f -exec sh -c "cvs -q log {} | grep 
> forv_ver1_020311-branch" \; -print 2>/dev/null |less
> [...]
> A rather brutal approach, you'll agree.

That's just the approach I'd have taken; but ouch!  I bet it took
a *long* time.  Try it this way instead:
        cvs log | egrep '^Working file:|forv_ver1_020311-branch'

It produces similar output:

    Working file: itp/build/b_wceupdate.bat
            forv_ver1_020311-branch: 1.2.0.8
    Working file: itp/build/foobar.bat
    Working file: itp/build/b_wceupdate2800.bat
            forv_ver1_020311-branch: 1.26.0.2

Advantages:
  - You'll get the Attic files too, since "cvs log" with no
    arguments DOES display deleted files (caveat; I know that's
    true of 1.11.2.1, and I'm fairly sure it's been true for a
    long time, but I can't say for sure that it's true of all
    versions)

  - It's *lots* faster.  Your way forks at least a couple of
    processes per file.

Disadvantage:
  - There'll be spurious filename lines for files without the
    tag, e.g. the "foobar.bat" line in the above sample

> Anyway, the odd thing is that I 
> have now rid this structure of files with a wrong tagging but the error 
> still is there. I wonder: could there be files in the Attic that are 
> screwing up my directory structure?

Maybe.  Or maybe you just need to repair the CVS state (fix the
CVS/Tag files or whatever it was) now that the underlying
condition has gone away (unless you've already tried that; you
don't say).

> Furthermore: is my very-large-ax approach a good was of searching for 
> this error?

Absolutely.  Just sub-optimally implemented :-)

> It there are files in the Attic that are acting up, how am I 
> going to find them? Should I search on the raw RCS files in the 
> repository instead? How do I adapt my script to do that? (I'm not fluent 
> in RCS at all)

"cvs log" is a wrapper for "rlog".  So it'd be something like:
        find $CVSROOT/itp -type f -name "*,v" | xargs rlog | egrep ...
Be warned that this will fail for pathnames containing shell
metacharacters, including spaces (those won't be a problem for
either your original approach or for my "cvs log | grep" one).
You can either work around that manually, or use GNU findutils as
I've described here recently (search the archives for "-print0"
[sic]).

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Just Say No to the "faceless cannonfodder" stereotype.
        - http://www.ainurin.net/ (an Orc site)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]