Re: import inconsistency

[Paul Edwards]

"Stefan Monnier" <monnier+gnu.cvs.bug/news/@flint.cs.yale.edu> wrote in message 
5l65naffjy.fsf@rum.cs.yale.edu">news:5l65naffjy.fsf@rum.cs.yale.edu...
> > I wouldn't use the words "forces me into exception coding" to
> > describe my feelings.  CVS is going through logic paths that
> > are specific to that file.  You can see reports that CVS even
> > has problems with a trailing "/" in $CVSROOT, so I don't
> > like to know that particular files in my repository are going
> > through unusual code.  I wouldn't mind so much if the files
> > in the Attic were dead and unimportant, but actually they are
> > every bit as live as the other ones.
>
> Files in the Attic is a very common place situation: every time someone adds
> a file to a branch before it's added to the trunk,

Very rare for a home user to do something like that.  You need
a big project to see something like that happening.

> or every time someone
> decides to remove a file from the trunk, you end up with the RCS file being
> moved to the Attic directory.

Once a file is removed, normally no-one cares about it.  It's
dead and forgotten.  In my case it is precious and remembered.

> I wouldn't call it "going through unusual code" and I expect that a bug in
> that code would be screamed up pretty quickly.

Nope, no reason for most people to be affected by that.  For
most people, when it goes into the Attic, it is because it is never
going to be looked at again.  In my case, I don't just want it looked
at, I want it treated as preciously as all the non-Attic files, in all
commands (cvs rdiff -s etc etc).

BTW, if these things were common, how come I was the first
to complain about cvs rdiff -s, first to complain about cvs diff
with two tags, first to complain about cvs diff not understanding
that dead means dead and no means no, first to complain that
branches interfere with normal import processing...  maybe the
underlying explanation is that I'm just a natural-born whinger
with too much time on his hands?  :-)

BFN.  Paul.