>> * How should the path be shown? *
>> \===============================/
...
>> Drawback: displaying something like
>> ../../somewhere/../whereisit/../a_here/path/stumble/file.txt
>> is not nice.
> Not nice... but expected if you try something like "fsvs st
> ../../somewhere/../whereisit/../a_here/path/stumble/"
>
> I think consistency with other cmd behaviour is important...
>> - Should a "./" be included or not? Wouldn't be needed, but shows that
>> they're only valid in *this* directory.
>>
> The "find" cmd behaviour seems to me the way to go:
>
> $ pwd
> /usr/src/fsvs-1.1.4
>
> $ find
> .
> ./CHANGES
> ./.svn
> ./.svn/prop-base
> ./.svn/props
> ./.svn/entries
> <snip>
>
>
> $ find $PWD
> /usr/src/fsvs-1.1.4
> /usr/src/fsvs-1.1.4/CHANGES
> /usr/src/fsvs-1.1.4/.svn
> /usr/src/fsvs-1.1.4/.svn/prop-base
> /usr/src/fsvs-1.1.4/.svn/props
> /usr/src/fsvs-1.1.4/.svn/entries
> <snip>
>
> $ cd src
> $ find ../
> ../
> ../CHANGES
> ../.svn
> ../.svn/prop-base
> ../.svn/props
> ../.svn/entries
>
> <snip>
>> But that just leaves more questions to answer ...
>> - Should ignore patterns be taken relative to the current subdirectory
>> of
>> the wc root, so that
>> $ fsvs ignore './*.txt'
>> is really
>> $ ( cd $WCROOT ; fsvs ignore './$OLD_WC/*.txt' )
>>
>> Or should ignore normally work as now, with a new "local-ignore"
>> command?
>>
> hmmm.... Something like that?
>
> $ find .
> ./a/1.txt
> ./a/2.txt
> ./a/3.jpg
> ./b/4.txt
> ./b/5.txt
> ./b/6.jpg
>
> $ fsvs local-ignore './*.txt'
> $ cd ./a
> $ fsvs st
> N... 3.jpg
> $ cd ../b
> $ fsvs st
> N... 6.jpg
> $ fsvs st ../a
> N... ../a/1.txt
> N... ../a/2.txt
> N... ../a/3.jpg
To be honest, I don't understand your example.
Do you mean to do a local-ignore in ./a? If not, why should a
(single-level) ignore pattern work in subdirectories?
> "A la" find / diff...
>
> But... why not give the choice between...
>
> - Relative to cmd (default) fsvs st ./ -> ./
> - Absolute "WC root" fsvs st -p ./ -> ./cur/subdir/of/wc
> - Absolute "File system root" fsvs st -pp ./ ->
> /path/to/my/wc/cur/subdir/of/wc
>
> So every need could be fulfilled...
Well, my current feeling is to use absolute paths, with environment
variables as shortcut.
That allows to copy a path and paste it in *any* other box - even in
browser upload/file open/other console windows ...
And users' directories would be abbreviated with $HOME anyway.
Of course, there's a lot to be said for argument-relative ...
But currently fsvs builds the tree, marks the entries, and runs through.
It doesn't do the same entry twice.
So what about this:
Currently:
$ fsvs st
.mC. 100 ./a/2.txt
Future:
$ fsvs st
.mC. 100 a/2.txt
$ fsvs st a
.mC. 100 a/2.txt
$ fsvs st a a/../a
.mC. 100 a/2.txt
.mC. 100 a/../a/2.txt
That would not work ATM.
My bash
GNU bash, version 3.1.17(1)-release (i486-pc-linux-gnu)
exports $PWD to child processes ... so an expansion like
$ fsvs st
.mC. 100 $PWD/a/2.txt
should always be possible. Of course, if I don't special-case this
variable (to ignore it), this path won't work in other windows ...
One of my often-needed use-cases is to see what has changed, and then do
some kind of cherry-picking copying - often in other windows, using scp or
rsync. If not a full path is given, this is not as easy.
I could use the currently open window - but then I'd have to scroll up and
search, because the results of some transfers would shift the list up ...
But I have to say, that *my* use-case shouldn't impact other people.
As soon as I find a volunteer (!!! Who wants??) to implement long option
names (like "--verbose") and get this names used in a configuration file
every user can set *persistent* defaults ... and defining different path
display variants seems to be necessary.
Hmmmm ... other ideas?
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
