Re: Added support for file list in single file update

[Shigio YAMAGUCHI]

2014-06-26 23:46 GMT+09:00 dhruva <address@hidden>:

Not in user visible out but 'yes' internally. When you give '+', gtags
assumes the file exists on disk without calling stat().
Without the '+', the stat() is called
- If the file does not exist (ENOENT or ESTALE), it is treated as deleted
- If exists, its time stamp is compared (default behavior without my change)

I understand.

The true meaning of the prefix is as follows, isn't it?

'-': This is a deletion.

'+': This is not a deletion.

'' : I don't know.

These prefixes are not a direction to gtags but a hint for

optimization. I think that this specification has two problems.

[Problems]

1. The meaning is not clear

It might be hard for users to understand the meaning of prefixes,

because it depends on the algorithm of the incremental updating

of gtags. A specification should be simple and clear. I also

didn't understand the meaning since I forgot the algorithm. :)

2. Path names are limited

You can not use path names which start with one of the prefixes.

[Suggestion]

How about using the following options?

This should solve above-mentioned problems.

--update-add=<added file list>

        Add files in the list to the present tag files

--update-delete=<deleted file list>

        Delete files in the list from the present tag files

--update-change=<changed file list>

        Change files in the list of the present tag files

With these options, you can issue not a hint but clear directions

to gtags. Though users are responsible for issuing right directions

which correspond to user visible realities, they are not required

to know the algorithm of incremental updating.

You can use them together,

$ gtags --update-add=file1 --update-delete=file2 --update-change=file3

...(1)

or, can use each of them independently.

$ gtags --update-add=file1              ... (2)

$ gtags --update-delete=file2           ... (3)

$ gtags --update-change=file3           ... (4)

(1) is equal to (2) + (3) + (4)

Your benchmark test and optimization has a meaning.

It should be possible in this specification, I belive.

What do you think?

--

Shigio YAMAGUCHI <address@hidden>

PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3