On Saturday 27 January 2007 14:54 Gunter Ohrner wrote:
> I'm now of the optinion that the majority of my problems
> seems to be sync-repos related.
...
> It does not happen always, but
> often, and I currently cannot predict when and how it happens, I just try
> if I find a way to trigger it.
>
> If it doesn't happen, fsvs seems to be as quick as it used to be in
> previous versions.
Yes, I forgot about the sync-repos before.
You could try this patch.
sync-repos currently looks at the processed directory, and if it has changed
locally (even if only the timestamp is different!), it marks the directory
as "to be checked next time" - because if the directory had changes, and the
entry list (possibly) gets other meta-data from the repository, this
directory wouldn't be seen as changed on the next run.
At least, that was my reasoning when I did that - but it may be completely
bogus. It made the tests pass - but they're not real-world tests, as there
are many changes in the same second (as you know :-)
Please try this way, or possibly by giving "-C" to the "sync-repos" (to
actually *read* the directories and look whether they've really changed).
The good news is - sync-repos will be completely changed in the near future.
The bad news is - sync-repos will be completely changed in the near future.
Take your bet :-)
Thank you & happy weekend!
=== sync.c
==================================================================
--- sync.c (revision 721)
+++ sync.c (local)
@@ -201,7 +201,7 @@
* repository yet.
* So set the flag to get it read on the next "status" command.
* Else we'd not show already existing entries! */
- sts->flags |= RF_CHECK;
+// sts->flags |= RF_CHECK;
ex:
RETURN_SVNERR(status);
--
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]
