Hello Roland!
>> But you're right; using multiple WCs with FSVS might easily make problems.
>> A repo-path should have only one _modifying_ WC.
>
> Is it hard to fix?
...
> I've C experience, but only limited time - worth to try?
Well, yes and no.
You've described the unfortunate case where no prior information was kept -
starting
afresh without local file lists, from revision 0 on.
Getting complete mixed working copies working is much work; I'm not sure how
much I
already managed to put into FSVS.
I think that for single URLs it should be fairly complete; and subversion
should throw
an error if we get conflicts on commit.
So, basically, it should work, provided that you don't start with an empty WC -
that
means doing an "fsvs update" or "fsvs sync-repos" _before_ working with a WC,
eg. simply
after defining the URLs.
You could put some code into FSVS that simply makes an update before
committing; that
might help a bit.
> We're planning to use fsvs to keep our cluster nodes in sync. Fsvs
> should be as transparent for the administrators as possible, if they
> can make changes in only one working set, I have to fight with them
> till my last blood. :)
>> If you really want to handle the same repository-directory, always use "fsvs
>> update"
>> before committing.
>
> Sounds like a reasonable workaround if proper fix isn't possible.
>
> (IMHO it's a critical bug for everyone who uses fsvs to keep cluster
> nodes in sync, because a node can outdate without any warning and that
> can cause annoying hard-to-find problems in the services of the load
> balanced cluster. Maybe you should put a message about it under "KNOWN
> BUGS" or "LIMITATIONS" section in the fsvs man page.)
Well, IIRC it shouldn't be that simple to trigger.
Apart from the hint above, there's always a simple workaround; "fsvs
sync-repos" will
fetch a completely fresh contents-list from the repository, and then show
changes as
usual.
So the recovery might simply be "fsvs sync-repos" and "fsvs revert / -R" (if
you're that
brave ;-)
The major problem I encountered (and which caused me to pause this project) was
the
complexity involved with more than one URL and mixed revision working copies.
I still plan to re-write FSVS, for true multi-URL operations ... sadly most of
my steam
was taken by discovering the "bup" project (backup into git repositories),
because
that's what the rewrite should have done (using git as backend).
What I'm trying to say with this is: Especially for cluster configuration it
might make
sense to have more than one URL - eg. one for the common data, and one per
node. Sadly
there are a few holes in FSVS for this use-case - having to run "fsvs update"
before
committing is one of them.
To wrap this all up - AFAIK FSVS is already used to sync contents between two
or more
nodes, so it should work fine for single-URL, well-initialized usage, apart
from the
leak when starting afresh; but please tell me if you discover other evidence ;-)
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
------------------------------------------------------
http://fsvs.tigris.org/ds/viewMessage.do?dsForumId=3928&dsMessageId=2735054
To unsubscribe from this discussion, e-mail:
[[email protected]].
