On Friday 29 February 2008, Marco S Hyman wrote:
>  > For the sake of new folks it may be wise to put a .cvsignore in
>  > our /usr/src tree to prevent unintended cosequences of using the
> (also > suggested) prune switch on cvs (-P).
>
> -P will only remove EMPTY directories that cvs knows about.   Putting
> xenocara (or in my case zenocara and ports) in /usr/src is pretty
> much a no-op when it comes to cvs.   A "cd /usr/src; cvs up -Pd"
> displays "? xenocara".  I can live with that.
>
>  > When following anoncvs.html, if a new person goes to update
>  > their /usr/src tree, they would thwack their /usr/src/xenocara
> tree.
>
> If the directory isn't empty it isn't thwacked
> If the directory isn't known by CVS it isn't thwacked.

You are correct about the thwacking and I failed to actually test it.
While trying to build a new -stable box from CD and looking over the
site docs/faq, I noticed the discrepancy and added a .cvsignore before
running any cvs update commands.... -But I'm odd that way, because I
actually enjoy going through the docs/faq at least once per release and
thinking about the suggested commands.

And yes, the "? xenocara" error/message is really very trivial.

But the question still stands; why does our documentation give suggested
methods which result in an error/message without explaining it?

I'm not concerned about long time users like you or me, or people who
are already familiar with UNIX and it's tools. But if this was your
very first adventure into CVS, both the docs and ways things work
should be clear and correct.

Yesterday I sent a diff to www@ to handle the XF4 -> xenocara changes
that were missed on release in anoncvs.html. Adding a one line
statement about .cvsignore and/or "? xenocara" to either anoncvs.html
or faq5.html would solve this, or alternatively we could just add
a .cvsignore to /usr/src

It's not a big deal, and is not really a "problem" that stops stuff from
working, but if we want our docs to be as clear and accuate as
possible, then we need to make a change (either document the issue, or
prevent it).

kind regards,
jcr

Reply via email to