Hello Stuart!
On Tuesday 26 August 2008 Stuart Lester wrote:
> We have a unique challenge that we're trying to address using fsvs. We
> have a lot of servers out "in the wild" as it were, and instead of using
> some sort of package management system to upgrade the OS and our own
> software, we want to use fsvs.
>
> The idea is that we can make updates on our own master server, check them
> into fsvs/subversion, and then have each of the "in the wild" servers
> update from fsvs/subversion. This seems like a great idea,
Yes, that's what FSVS is for.
> but we've had a
> bit of difficulty when trying to actually get these updates to work.
>
> In our testing environment, we'll make some changes and then commit them
> fine, but when we try to do an update, we will often (but not always) get
> something like the following:
>
> dev-01 / # fsvs update -r 19
> Updating svn+ssh://[EMAIL PROTECTED]//home/user/svn/osrepo to revision
> 19.
> The entry ./etc/fsvs has changed locally
I cannot reproduce that for a directory.
And /etc/fsvs shouldn't have changed - possibly the files two levels below.
> We've tried with and without the "-r <revision>", and we don't always get
> the same file as having changed (though it is usually one of a handful of
> files).
Is that really a file? /etc/fsvs is normally a directory.
> I'm fairly certain that the file in question has not in fact
> changed. One thing we've tried is doing a revert just before an update,
> but that doesn't seem to fix it.
Well, it should "just work".
The only thing a "revert" would do is in case of a conflict - and that could
be equally handled on "update" via the "conflict" option.
> We really like fsvs, from a conceptual level, and it seems like the right
> solution, but this has us pulling our hair out. Can anyone shine any light
> on the situation?
I'll try :-)
> Is this an imporper use of this package?
No.
> Are we missing something obvious?
No.
> I can elaborate on our setup and such, if that would be
> helpful, but I don't want to dump a bunch of configs on this list if it
> isn't necessary.
Thank you.
I'd expect you'll likely have a problem that you put /etc/fsvs in the
repository, although *both* the master server and the clients use it.
The master server updates the file on every commit, and the clients want to
change it on every update - and therefore each sees it as changed.
If it's only something in /etc/fsvs, you could simply ignore that hierarchy -
see "fsvs ignore" and "fsvs unversion" for that.
Otherwise, do you possibly commit log files that change on the clients as
well?
If that doesn't solve your problem - could you do a "fsvs log -r19 -v" to see
which entries have changed in that revision, and a "fsvs st" on the client
before running "update"?
BTW I'm currently working on fixing a bug that happens when you try a "revert"
on type-changing entries (symlink -> dir, file -> device, etc.); "update" is
fine, though.
Regards,
Phil
--
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]
