Re: Re: Documenation update

About all the man page stuff. I think we can ignore my statements on
it... I use(d) vim as man browser, which, I just discovered, messed up
the entire layout. Using the normal man browser, the man page is clear
enough.


Denis Corbin wrote:

> I can now see something interesting to do about man pages :
>
> dar.1 -> general presentation of the command line tool
> dar_filtering.1 -> all that concerns the filtering -am, -I -X, -g, -P,
> -[, -] -u, -U, -ac, -an
> dar_ea -> all that concerns EA
> dar_create.1 -> all that concerns archive creation (differential/full
> backup/snapshot)
> dar_isolate.1 -> all that concerns catalogue isolation
> dar_merge.1 -> all that concerns archive merging
> dar_test.1 -> all that concerns testing
> dar_diff.1 -> all that concerns diffing
> dar_list.1 -> all that concerns listing (normal,tree-like,XML listings)
>
> with cross references between theses pages. 

No "extraction" man page?

But I'm not sure I like this approach. For example, you'll have issues
with where to put options like --alter=atime, which are for create and
compare. With this approach, you run the risk of not putting something
where it is expected. A user may end up not reading an important option,
because he's in the wrong manpage, which could make his backup unusable
without his knowledge, or mess up his system (the --alter=ctime comes to
mind...)

My discovery about vim messing up the layout negates any problems I had
with the man page.


Denis Corbin wrote:

> the -am description refers to a section above in the man page about
> file filtering, where is described two ways of building a filter based
> on -I -X, -P, -g -[ and -] options. Does this paragraph is not correct
> or could not you find the reference given in the option description
> (in that case a separated man page would be more interesting)? 

With the help of Wesley's elaborate explanation, I'll try to figure the
option out, and come up with some documentation about it.


Wesley Leggette wrote

>I don't know how Denis wants to handle it, but it is sometimes
>advantageous to provide patches. Do you know how to do this?
>

Denis Corbin wrote:

> Definitively yes. This would avoid me forgetting treating tasks and
> eases the review of changes. As I cannot treat patches as soon as they
> are available, using the sourceforge tracker lets the possibility to
> other users to know about pending patches and let users applying them
> while they are not yet integrated into CVS.
>
> But that's OK to post here (as we have asked you to do so :-) )

I have no problem with writing patches. I've checked out the source and
will make patches. Do you want me to submit the sections I've already
posted here to the patch tracker?

Using CVS instead of SVN is new to me, so if I run into problems, I'll
ask :)

Wesley, I think I covered/used everything you said in your message. I
may get back to the explanation of --alter=mask when I get to rewriting
that section of the manpage. I hope you don't feel too much ignored :).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEJobPMHkUjYo9d9ARAmVdAKC+tInDQynTYvP74vyaQjocrOc/GwCgiuae
OTEPKCGAggNMBedS+29nEOU=
=H1DR
-----END PGP SIGNATURE-----