Convert the other caches.
Let the apr_uid_get()
calls from update.c
go into that - but they need a hash or something like that. Maybe reverse the test and look whether the number (eg. uid) matches the string (username)?
Do we really need to load the URLs here? They're needed for associating the entries - but maybe we should do that two-way:
intnum
, and store it again(struct url_t*)
.-0 like for xargs?
Are different revision numbers for load
necessary? Should dump
print the source revision number?
Copying from URLs means update from there
Filter for dump (patterns?).
some parameter that just prints the "best" match, and outputs the correct format.
Two revisions diff is buggy in that it (currently) always fetches the full trees from the repository; this is not only a performance degradation, but you'll see more changed entries than you want (like changes A to B to A). This will be fixed.
Another limitation is that just-deleted just-committed entries cannot be fetched via revert
, as FSVS no longer knows about them.
TODO: If a revision is given, take a look there, and ignore the local data?
As a workaround you could use the cat and/or checkout commands to fetch repository-only data.
Build the wc_relative_path
only if necessary - remove the parameter from the caller chains.
We should set it beginning from a command line parameter, if we have one. Preferably the nearest one ...
Currently all patterns get tested against all new entries. This does not seem to be a performance problem.
When we do a rsync-copy from the repository, we'll have to look at that again! Either we write the last block too, or we'll have to ask for the last few bytes extra.
A further optimization would be to check if a parent is already present, and append to that path. Similar for a neighbour entry.
by_inode
and by_name
arrays. getenv()
over all options? --xml, --raw, --dump switches?
should prop-get and prop-list use UTF-8 or local encoding? Currently the names and values are dumped as-is, ie. UTF-8.
if it's NULL
, but an update-pipe is set on the entry, the data has to be read from disk again, to be correctly processed.
is 1024 bytes always enough? Maybe there's an RFC. Make that dynamically - look how much we'll need.
: writev
Should that be changed to base="/"?
strlen
("const") initializers. See debian bug #60xxxx. And see below for WAA_PATH, too. Currently hardlinks with duplicate inode-numbers are not well done in fsvs.