Login | Register
My pages Projects Community openCollabNet

Discussions > users > Re: fsvs use case

fsvs
Discussion topic

Hide all messages in topic

All messages in topic

Re: fsvs use case

Author pmarek
Full name P.Marek
Date 2008-08-30 00:03:29 PDT
Message Hello Stuart!

On Friday 29 August 2008 Stuart Lester wrote:
> I'm not sure about why this is happenig...but this is driving me
> crazy.
I'm sorry about that.

> Now, after I thought we had the problems behind us. I found a
> file that should be on the OS (it is in subversion, but refuses to
> show up in a status and remote-status), but isn't.
It might have been interesting what "fsvs info <filename>" would have said.

> So, I "bumped" the
> file on the "master" system, and re-ran the "fsvs update
> -oconflict=remote -d" command, and got this error (only the last few
> lines included):
...
> 15:23:28.143 ops__find_entry_byna​me[est_ops.c:781]
> Searching for create_schema.sql (create_schema.sql)
> found no entry (ignored_too=0)
> 15:23:28.143 cb__add_entry[racallback.c:165] entry
> opt/myoffice/sql/cre​ate_schema.sql, mode 0100000;
> not found, may not create
>
> An error occurred at 15:23:28.187: No such file or directory (2)
> in cb__record_changes_mixed [racallback.c:834]:
> reporter->finish_report: cb___open_file
> 15:23:28.187 main[fsvs.c:1261] memory stats: 0x807e000 to 0x81e9000, 1452
> KB
It seems that your entry lists are messed up completely. Maybe because you had
them committed some time.

Please run "fsvs sync-repos" on the clients (possibly with a revision
parameter) - that should re-build a clean entry list from the repository.

> I _really_ want this solution to work. It seems quite elegant and
> feels like the most appropriate solution for us. The problem is that
> I'm starting to get some push from other team members to move to other
> solutions.
Well, what are the alternatives?
For simple versioning you could use git - but that uses a local repository (=>
space), or svn (not that space-efficient, too) - or mercurial or ... ?

Alone that multiple URLs can be overlayed (a base, and a machine-specific) is
a major point for FSVS, which (AFAIK) no other product has.

> The fact is, we _can_not_ use the fsvs if it is so
> unpredictable.
That's understandable.

> Could we have messed up something in the compile?
Don't think so.

> Could we have messed up something in the repository initialization?
Don't think so, either - my guess is the local entry-list.

> Could we have some odd config settings that are interfeering with the
> running of this?
No. None that I know of.

> At this point, I think something is wrong with our setup, since there
> does appear to be plenty of people that have successfully used this
> system. My goal is to find out what we're doing wrong/differently,
> and fix it. Let me know and I can send/post all of my configs,
> including the commands I'm using to initialize/update the system.
Well, let's try with "sync-repos"; if that's not enough we could do a debug
session some evening (for me)/afternoon (for you) [since we've got 7hrs
difference].

> Again, I really do appreciate all of your help (especially Phil).
> Thanks in advance for any thoughts you can offer.
You're welcome. Nothings too much if you're striving for world dominance ;-)


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: fsvs use case

Author Stuart Lester <stuart dot lester at gmail dot com>
Full name Stuart Lester <stuart dot lester at gmail dot com>
Date 2008-08-29 12:27:55 PDT
Message I'm not sure about why this is happenig...but this is driving me
crazy. Now, after I thought we had the problems behind us. I found a
file that should be on the OS (it is in subversion, but refuses to
show up in a status and remote-status), but isn't. So, I "bumped" the
file on the "master" system, and re-ran the "fsvs update
-oconflict=remote -d" command, and got this error (only the last few
lines included):

15:23:28.143 up__parse_prop[update.c:165] got property for sql:
svn:entry:committed-rev=39
15:23:28.143 cb___store_prop[raca​llback.c:292] have
name=svn:entry:committed-rev; user? 0
15:23:28.143 up__parse_prop[update.c:165] got property for sql:
svn:entry:committed-​date=2008-08-29T18:5​9:37.704186Z
15:23:28.143 cb___store_prop[raca​llback.c:292] have
name=svn:entry:committed-date; user? 0
15:23:28.143 up__parse_prop[update.c:165] got property for sql:
svn:entry:last-author=user
15:23:28.143 cb___store_prop[raca​llback.c:292] have
name=svn:entry:last-author; user? 0
15:23:28.143 up__parse_prop[update.c:165] got property for sql:
svn:entry:uuid=9b534​c72-a6ac-4330-b533-7​5b76ca60dff
15:23:28.143 cb___store_prop[raca​llback.c:292] have name=svn:entry:uuid; user? 0
15:23:28.143 ops__find_entry_byna​me[est_ops.c:781] Searching for
create_schema.sql (create_schema.sql) found no entry (ignored_too=0)
15:23:28.143 cb__add_entry[racallback.c:165] entry
opt/myoffice/sql/cre​ate_schema.sql, mode 0100000; not found, may not
create

An error occurred at 15:23:28.187: No such file or directory (2)
  in cb__record_changes_mixed [racallback.c:834]:
reporter->finish_report: cb___open_file
15:23:28.187 main[fsvs.c:1261] memory stats: 0x807e000 to 0x81e9000, 1452 KB

I _really_ want this solution to work. It seems quite elegant and
feels like the most appropriate solution for us. The problem is that
I'm starting to get some push from other team members to move to other
solutions. The fact is, we _can_not_ use the fsvs if it is so
unpredictable.

Could we have messed up something in the compile?

Could we have messed up something in the repository initialization?

Could we have some odd config settings that are interfeering with the
running of this?

At this point, I think something is wrong with our setup, since there
does appear to be plenty of people that have successfully used this
system. My goal is to find out what we're doing wrong/differently,
and fix it. Let me know and I can send/post all of my configs,
including the commands I'm using to initialize/update the system.

Again, I really do appreciate all of your help (especially Phil).
Thanks in advance for any thoughts you can offer.

Stu

On Fri, Aug 29, 2008 at 2:32 PM, Philipp Marek <philipp at marek dot priv dot at> wrote:
> On Friday 29 August 2008 Stuart Lester wrote:
>> A little progress (and maybe a resolution). You mentioned the
>> "conflict" option in an earlier reply/post. I think that's probably
>> key to resolving this...we want to set that to "remote". I don't know
>> how to do that. I believe, after looking through the docs, that the
>> option we need is:
>> -oconflict=remote
>>
>> Is this correct?
> Yes, for the commandline.
> But you could use that in the $FSVS_CONF/config file (or the WC-specific),
> too.
>
>
> But that should just be a workaround - why are these files reported as
> changed? For a directory I could understand it if files below are
> added/removed - but that doesn't cause this error for me.
>
>
> Regards,
>
> Phil
>
>
> --
> Versioning your /etc, /home or even your whole installation?
> Try fsvs (fsvs.tigris.org)!
>

Re: fsvs use case

Author pmarek
Full name P.Marek
Date 2008-08-29 11:32:20 PDT
Message On Friday 29 August 2008 Stuart Lester wrote:
> A little progress (and maybe a resolution). You mentioned the
> "conflict" option in an earlier reply/post. I think that's probably
> key to resolving this...we want to set that to "remote". I don't know
> how to do that. I believe, after looking through the docs, that the
> option we need is:
> -oconflict=remote
>
> Is this correct?
Yes, for the commandline.
But you could use that in the $FSVS_CONF/config file (or the WC-specific),
too.


But that should just be a workaround - why are these files reported as
changed? For a directory I could understand it if files below are
added/removed - but that doesn't cause this error for me.


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: fsvs use case

Author Stuart Lester <stuart dot lester at gmail dot com>
Full name Stuart Lester <stuart dot lester at gmail dot com>
Date 2008-08-29 08:21:37 PDT
Message Phil,
A little progress (and maybe a resolution). You mentioned the
"conflict" option in an earlier reply/post. I think that's probably
key to resolving this...we want to set that to "remote". I don't know
how to do that. I believe, after looking through the docs, that the
option we need is:
  -oconflict=remote

Is this correct?

Stu

On Fri, Aug 29, 2008 at 9:36 AM, Stuart Lester <stuart dot lester at gmail dot com> wrote:
> For what it's worth...it appears as though, on the system being
> updated, any file that is updated causes this conflict...in a fit of
> desperation, I'm deleting each file as it causes the error, just to
> see if we can get the system to an "updated" state.
>
> Stu
>
> On Fri, Aug 29, 2008 at 9:30 AM, Stuart Lester <stuart dot lester at gmail dot com> wrote:
>> That worked...except now I'm seeing the error on files:
>> dev-01 / # fsvs update
>> Updating svn+ssh://user@svnse​rver//home/hydra/svn​/obx to revision 35.
>> .m.. dir dev
>> .m.. dir etc
>> .mC. 1323 opt/hydra-client/bin/restore.sh
>> .mC. 1830 opt/hydra-client/bin/backup.sh
>> .m.. dir opt/hydra-client/bin
>> .m.. dir opt/hydra-client/tem​plates/etc/samba
>> .m.. 12 var/db/pkg/dev-util/​fsvs-1.1.16/PF
>> .m.. 42 var/db/pkg/dev-util/​fsvs-1.1.16/USE
>> .m.. 2 var/db/pkg/dev-util/​fsvs-1.1.16/EAPI
>> .m.. 24 var/db/pkg/dev-util/​fsvs-1.1.16/HOMEPAGE​
>> .m.. 2 var/db/pkg/dev-util/​fsvs-1.1.16/SLOT
>> The entry ./var/db/pkg/dev-uti​l/fsvs-1.1.16/CONTEN​TS has changed locally
>>
>> Stu
>>
>> On Fri, Aug 29, 2008 at 5:00 AM, Philipp Marek <philipp at marek dot priv dot at> wrote:
>>> Hello Stuart!
>>>
>>> On Thursday 28 August 2008 Stuart Lester wrote:
>>>> Hey, at this point, I'll take all the help I can get...
>>>>
>>>> I ran the following command to generate the log:
>>>>
>>>> dev-01 log # fsvs update -d > /var/log/fsvs_update.log 2>&1
>>>>
>>>> This created a BIG file (400MB+) and was still rather large when
>>>> gzip-ed (30MB). Instead, I took the last 100,000 lines and zipped
>>>> them up....if you need the whole thing, just let me know.
>>>
>>> The important line is this:
>>>> 14:19:10.054 rev___undo_change[revert.c:960]
>>>> ./opt/hydra-client/bin has changed: mode=040775,
>>>> r=220(mtime, child),
>>>> l=228(mtime, child, likely)
>>>
>>> Does the attached patch help?
>>> It should at least paper over the problem.
>>>
>>> I still don't know why I can't reproduce that, but I'll try harder :-)
>>>
>>>
>>>
>>> Index: revert.c
>>> ====================​====================​====================​=======
>>> --- revert.c (Revision 1872)
>>> +++ revert.c (Arbeitskopie)
>>> @@ -961,8 +961,10 @@ int rev___undo_change(struct estat *sts,
>>>
>>> unique_name_mine=NULL;
>>>
>>> - /* Conflict handling; depends whether it has changed locally. */
>>> - if (sts->entry_status & (FS_CHANGED | FS_CHILD_CHANGED))
>>> + /* Conflict handling; depends whether it has changed locally.
>>> + * Directories have no conflict (unless they're replaced).
>>> + * \todo: Need test-cases for that. */
>>> + if (!S_ISDIR(sts->st.mode) && (sts->entry_status & FS_CHANGED))
>>> switch (opt__get_int(OPT__CONFLICT))
>>> {
>>> case CONFLICT_STOP:
>>>
>>>
>>> --
>>> Versioning your /etc, /home or even your whole installation?
>>> Try fsvs (fsvs.tigris.org)!
>>>
>>> --------------------​--------------------​--------------------​---------
>>> To unsubscribe, e-mail: users-unsubscribe@fs​vs.tigris.org
>>> For additional commands, e-mail: users-help at fsvs dot tigris dot org
>>>
>>>
>>
>

Re: fsvs use case

Author Stuart Lester <stuart dot lester at gmail dot com>
Full name Stuart Lester <stuart dot lester at gmail dot com>
Date 2008-08-29 06:36:53 PDT
Message For what it's worth...it appears as though, on the system being
updated, any file that is updated causes this conflict...in a fit of
desperation, I'm deleting each file as it causes the error, just to
see if we can get the system to an "updated" state.

Stu

On Fri, Aug 29, 2008 at 9:30 AM, Stuart Lester <stuart dot lester at gmail dot com> wrote:
> That worked...except now I'm seeing the error on files:
> dev-01 / # fsvs update
> Updating svn+ssh://user@svnse​rver//home/hydra/svn​/obx to revision 35.
> .m.. dir dev
> .m.. dir etc
> .mC. 1323 opt/hydra-client/bin/restore.sh
> .mC. 1830 opt/hydra-client/bin/backup.sh
> .m.. dir opt/hydra-client/bin
> .m.. dir opt/hydra-client/tem​plates/etc/samba
> .m.. 12 var/db/pkg/dev-util/​fsvs-1.1.16/PF
> .m.. 42 var/db/pkg/dev-util/​fsvs-1.1.16/USE
> .m.. 2 var/db/pkg/dev-util/​fsvs-1.1.16/EAPI
> .m.. 24 var/db/pkg/dev-util/​fsvs-1.1.16/HOMEPAGE​
> .m.. 2 var/db/pkg/dev-util/​fsvs-1.1.16/SLOT
> The entry ./var/db/pkg/dev-uti​l/fsvs-1.1.16/CONTEN​TS has changed locally
>
> Stu
>
> On Fri, Aug 29, 2008 at 5:00 AM, Philipp Marek <philipp at marek dot priv dot at> wrote:
>> Hello Stuart!
>>
>> On Thursday 28 August 2008 Stuart Lester wrote:
>>> Hey, at this point, I'll take all the help I can get...
>>>
>>> I ran the following command to generate the log:
>>>
>>> dev-01 log # fsvs update -d > /var/log/fsvs_update.log 2>&1
>>>
>>> This created a BIG file (400MB+) and was still rather large when
>>> gzip-ed (30MB). Instead, I took the last 100,000 lines and zipped
>>> them up....if you need the whole thing, just let me know.
>>
>> The important line is this:
>>> 14:19:10.054 rev___undo_change[revert.c:960]
>>> ./opt/hydra-client/bin has changed: mode=040775,
>>> r=220(mtime, child),
>>> l=228(mtime, child, likely)
>>
>> Does the attached patch help?
>> It should at least paper over the problem.
>>
>> I still don't know why I can't reproduce that, but I'll try harder :-)
>>
>>
>>
>> Index: revert.c
>> ====================​====================​====================​=======
>> --- revert.c (Revision 1872)
>> +++ revert.c (Arbeitskopie)
>> @@ -961,8 +961,10 @@ int rev___undo_change(struct estat *sts,
>>
>> unique_name_mine=NULL;
>>
>> - /* Conflict handling; depends whether it has changed locally. */
>> - if (sts->entry_status & (FS_CHANGED | FS_CHILD_CHANGED))
>> + /* Conflict handling; depends whether it has changed locally.
>> + * Directories have no conflict (unless they're replaced).
>> + * \todo: Need test-cases for that. */
>> + if (!S_ISDIR(sts->st.mode) && (sts->entry_status & FS_CHANGED))
>> switch (opt__get_int(OPT__CONFLICT))
>> {
>> case CONFLICT_STOP:
>>
>>
>> --
>> Versioning your /etc, /home or even your whole installation?
>> Try fsvs (fsvs.tigris.org)!
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: users-unsubscribe@fs​vs.tigris.org
>> For additional commands, e-mail: users-help at fsvs dot tigris dot org
>>
>>
>

Re: fsvs use case

Author Stuart Lester <stuart dot lester at gmail dot com>
Full name Stuart Lester <stuart dot lester at gmail dot com>
Date 2008-08-29 06:30:56 PDT
Message That worked...except now I'm seeing the error on files:
dev-01 / # fsvs update
Updating svn+ssh://user@svnse​rver//home/hydra/svn​/obx to revision 35.
.m.. dir dev
.m.. dir etc
.mC. 1323 opt/hydra-client/bin/restore.sh
.mC. 1830 opt/hydra-client/bin/backup.sh
.m.. dir opt/hydra-client/bin
.m.. dir opt/hydra-client/tem​plates/etc/samba
.m.. 12 var/db/pkg/dev-util/​fsvs-1.1.16/PF
.m.. 42 var/db/pkg/dev-util/​fsvs-1.1.16/USE
.m.. 2 var/db/pkg/dev-util/​fsvs-1.1.16/EAPI
.m.. 24 var/db/pkg/dev-util/​fsvs-1.1.16/HOMEPAGE​
.m.. 2 var/db/pkg/dev-util/​fsvs-1.1.16/SLOT
The entry ./var/db/pkg/dev-uti​l/fsvs-1.1.16/CONTEN​TS has changed locally

Stu

On Fri, Aug 29, 2008 at 5:00 AM, Philipp Marek <philipp at marek dot priv dot at> wrote:
> Hello Stuart!
>
> On Thursday 28 August 2008 Stuart Lester wrote:
>> Hey, at this point, I'll take all the help I can get...
>>
>> I ran the following command to generate the log:
>>
>> dev-01 log # fsvs update -d > /var/log/fsvs_update.log 2>&1
>>
>> This created a BIG file (400MB+) and was still rather large when
>> gzip-ed (30MB). Instead, I took the last 100,000 lines and zipped
>> them up....if you need the whole thing, just let me know.
>
> The important line is this:
>> 14:19:10.054 rev___undo_change[revert.c:960]
>> ./opt/hydra-client/bin has changed: mode=040775,
>> r=220(mtime, child),
>> l=228(mtime, child, likely)
>
> Does the attached patch help?
> It should at least paper over the problem.
>
> I still don't know why I can't reproduce that, but I'll try harder :-)
>
>
>
> Index: revert.c
> ====================​====================​====================​=======
> --- revert.c (Revision 1872)
> +++ revert.c (Arbeitskopie)
> @@ -961,8 +961,10 @@ int rev___undo_change(struct estat *sts,
>
> unique_name_mine=NULL;
>
> - /* Conflict handling; depends whether it has changed locally. */
> - if (sts->entry_status & (FS_CHANGED | FS_CHILD_CHANGED))
> + /* Conflict handling; depends whether it has changed locally.
> + * Directories have no conflict (unless they're replaced).
> + * \todo: Need test-cases for that. */
> + if (!S_ISDIR(sts->st.mode) && (sts->entry_status & FS_CHANGED))
> switch (opt__get_int(OPT__CONFLICT))
> {
> case CONFLICT_STOP:
>
>
> --
> Versioning your /etc, /home or even your whole installation?
> Try fsvs (fsvs.tigris.org)!
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: users-unsubscribe@fs​vs.tigris.org
> For additional commands, e-mail: users-help at fsvs dot tigris dot org
>
>

Re: fsvs use case

Author pmarek
Full name P.Marek
Date 2008-08-29 02:00:47 PDT
Message Hello Stuart!

On Thursday 28 August 2008 Stuart Lester wrote:
> Hey, at this point, I'll take all the help I can get...
>
> I ran the following command to generate the log:
>
> dev-01 log # fsvs update -d > /var/log/fsvs_update.log 2>&1
>
> This created a BIG file (400MB+) and was still rather large when
> gzip-ed (30MB). Instead, I took the last 100,000 lines and zipped
> them up....if you need the whole thing, just let me know.

The important line is this:
> 14:19:10.054 rev___undo_change[revert.c:960]
> ./opt/hydra-client/bin has changed: mode=040775,
> r=220(mtime, child),
> l=228(mtime, child, likely)

Does the attached patch help?
It should at least paper over the problem.

I still don't know why I can't reproduce that, but I'll try harder :-)



Index: revert.c
====================​====================​====================​=======
--- revert.c (Revision 1872)
+++ revert.c (Arbeitskopie)
@@ -961,8 +961,10 @@ int rev___undo_change(struct estat *sts,

        unique_name_mine=NULL;

- /* Conflict handling; depends whether it has changed locally. */
- if (sts->entry_status & (FS_CHANGED | FS_CHILD_CHANGED))
+ /* Conflict handling; depends whether it has changed locally.
+ * Directories have no conflict (unless they're replaced).
+ * \todo: Need test-cases for that. */
+ if (!S_ISDIR(sts->st.mode) && (sts->entry_status & FS_CHANGED))
                switch (opt__get_int(OPT__CONFLICT))
                {
                        case CONFLICT_STOP:


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: fsvs use case

Author pmarek
Full name P.Marek
Date 2008-08-28 09:09:01 PDT
Message Hello Stuart,

On Thursday 28 August 2008 Stuart Lester wrote:
> We're _still_ getting this error. Here's an example:
> dev-01 / # fsvs update
> Updating svn+ssh://user@svnse​rver//home/hydra/svn​/obx to revision 34.
> .m.. dir dev
> .mC. 1830 opt/hydra-client/bin/backup.sh
> .mC. 1323 opt/hydra-client/bin/restore.sh
> .m.. dir opt/hydra-client/bin
> .m.. dir opt/hydra-client/tem​plates/etc/samba
> .m.. dir var/lib/ntp
...
> The entry ./root has changed locally
>
> /root is a directory.
> I got that same error a couple of times. Then, I ran "fsvs
> remote-status" and re-ran the command:
>
> dev-01 / # fsvs update
> Updating svn+ssh://user@svnse​rver//home/hydra/svn​/obx to revision
> 34. .m.. dir dev
> The entry ./opt/hydra-client/bin has changed locally
So an entry that worked the first time doesn't the second time?

> Sigh.
Sorry.

> Any suggestions to how to debut/troubleshoot this?
Well, let me explain a bit.
I *designed* FSVS to not be atomic - because trying to be atomic for some
thousand (or more) files with some GB in them isn't possible with POSIX.
I hope for unionfs to be in mainline sometime - then the update would be in a
(transparently) overlayed directory, and if everything is fetched (update
complete) the root filesystem would get the overlayed directory mounted (in a
union), too.
Voila! Instant atomic operation, regardless of the update size.

So what's currently possible with FSVS (doing live update) is
* a necessity for most (or even all) users, and
* not what FSVS is designed for.

Just to have a bit of background.


Now, to your specific problem - that shouldn't happen this way.
Never.
But my problem is: I cannot reproduce that.
I add/delete entries from a directory, chmod and chown it - I don't get the
conflict that you show.

Would you please (privately, if you prefer) send me the output of the "update"
statement above, with "-d" added?
If you don't want to (because there may be pathnames you don't want to show
this way), we can try to debug that over IRC or something similar - that's
more real-time than email.
(But mail is fine, too, if you don't have any other way.)


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: fsvs use case

Author Stuart Lester <stuart dot lester at gmail dot com>
Full name Stuart Lester <stuart dot lester at gmail dot com>
Date 2008-08-28 08:14:47 PDT
Message Phil (and everyone else),
We're _still_ getting this error. Here's an example:
dev-01 / # fsvs update
Updating svn+ssh://user@svnse​rver//home/hydra/svn​/obx to revision 34.
.m.. dir dev
.mC. 1830 opt/hydra-client/bin/backup.sh
.mC. 1323 opt/hydra-client/bin/restore.sh
.m.. dir opt/hydra-client/bin
.m.. dir opt/hydra-client/tem​plates/etc/samba
.m.. dir var/lib/ntp
.m.. dir var/lib/mysql/mysql
.m.. dir var/lib/mysql/phpmyadmin
.m.. dir var/lib/mysql/ids_data
.m.. dir var/lib/mysql/pbx_data
.m.. dir var/lib/mysql/monitor_data
.m.. dir var/lib/mysql/myoffice_data
.m.. dir var/lib/slocate
.m.. dir var/lib/init.d
.m.. dir var/run/cups/certs
.m.. dir var/cache/samba
.m.. dir var/cache/logwatch
.m.. dir var/spool/cron/lastrun
.m.. dir var/spool/fsvs
.m.. dir var/spool/postfix/maildrop
.m.. dir var/spool/postfix/active
.m.. dir var/spool/postfix/bounce
.m.. dir var/spool/postfix/incoming
.m.. dir var/spool/asterisk/v​oicemail/device
.m.. 0 usr/local/share/man/whatis
The entry ./root has changed locally

/root is a directory.
I got that same error a couple of times. Then, I ran "fsvs
remote-status" and re-ran the command:

dev-01 / # fsvs update
Updating svn+ssh://user@svnse​rver//home/hydra/svn​/obx to revision 34.
.m.. dir dev
The entry ./opt/hydra-client/bin has changed locally

Sigh.

Any suggestions to how to debut/troubleshoot this?

Stu

On Wed, Aug 27, 2008 at 12:05 PM, Philipp Marek <philipp at marek dot priv dot at> wrote:
> Hello Stuart!
>
>> The /opt/hydra-client/hy​dra_client/task_scri​pts directory does show as
>> being "m", but I don't understand why that would mess up the update?
> Me neither. "m" means meta-data - that shouldn't be a conflict.

Re: fsvs use case

Author griffon26
Full name Maurice van der Pot
Date 2008-08-27 11:50:22 PDT
Message On Wed, Aug 27, 2008 at 06:05:14PM +0200, Philipp Marek wrote:
> > Finally, fwiw, a while back, I submitted a gentoo ebuild (their
> > equivalent of RPM) to that project (as Gentoo is our OS of choice).
> > It's an old version (1.1.9), but someone did update it to 1.1.16.
> > Unfortunately, though, it hasn't yet been accepted into their official
> > tree. Anyhow, just trying to give a little back.
> Thank you; maybe they'll take it some time.

I plan on taking up maintenance of the ebuild once I've made my final
decision to keep using fsvs.

Regards,
Maurice.

--
Maurice van der Pot

Gentoo Linux Developer griffon26 at gentoo dot org http://www.gentoo.org
Gnome Planner Developer griffon26 at kfk4ever dot com http://live.gnome.org/Planner
Attachments

Re: fsvs use case

Author pmarek
Full name P.Marek
Date 2008-08-27 09:05:14 PDT
Message Hello Stuart!

On Wednesday 27 August 2008 Stuart Lester wrote:
> > 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.
>
> We've now corrected this.
Ok; maybe that's enough to avoid that problem in the future.

> The /opt/hydra-client/hy​dra_client/task_scri​pts directory does show as
> being "m", but I don't understand why that would mess up the update?
Me neither. "m" means meta-data - that shouldn't be a conflict.

> Finally, fwiw, a while back, I submitted a gentoo ebuild (their
> equivalent of RPM) to that project (as Gentoo is our OS of choice).
> It's an old version (1.1.9), but someone did update it to 1.1.16.
> Unfortunately, though, it hasn't yet been accepted into their official
> tree. Anyhow, just trying to give a little back.
Thank you; maybe they'll take it some time.


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: fsvs use case

Author Stuart Lester <stuart dot lester at gmail dot com>
Full name Stuart Lester <stuart dot lester at gmail dot com>
Date 2008-08-27 07:45:39 PDT
Message Phil et al,

On Wed, Aug 27, 2008 at 4:44 AM, Philipp Marek <philipp at marek dot priv dot at> wrote:
>
> Hello Stuart!
>
> On Tuesday 26 August 2008 Stuart Lester wrote:
> > 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://user@svnse​rver//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.

I must admit, I did not see that _exact_ error when I pasted earlier.
I do know that I saw it previously, and I figured that directory would
useful to post than the actual one that I posted. Here is my latest
error (with only the username/hostname changed):

dev-01 / # fsvs update -r 19
Updating svn+ssh://user@svnse​rver//home/hydra/svn​/obx to revision 19.
The entry ./opt/hydra-client/h​ydra_client/task_scr​ipts has changed locally

The entry in question is in fact a directory. I'm fairly certian that
I have not changed it...this was a clean install followed by a series
of "fsvs update" commands.

> > 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.

Definitely a directory.

> 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.

We've now corrected this...having /etc/fsvs in the repository has
always been a nagging concern of mine, but I didn't know how to
otherwise reflect updates to the Ign file. I have a solution for that
now, so no worries.

> 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?

We have ignored all log files, and that doesn't seem to be the problem.

> 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"?

dev-01 / # fsvs log -r19 -v
--------------------​--------------------​--------------------​------------
r19 | hydra | 2008-08-20T20:57:14.013041Z | 1 line
Changed paths:
  /opt/hydra-client/hy​dra_client/task_scri​pts
  /opt/vmware/server/l​ib/libconf/etc/pango​/pangorc
  /opt/vmware/server/l​ib/serverd/init.pl
  /opt/hydra-client/te​mplates/boot/grub/gr​ub.conf
  /opt/vmware/server/l​ib/libconf/etc/pango​
  /opt/vmware/server/l​ib/libconf/etc/gtk-2​.0/gtk.immodules
  /opt/jungledisk/etc
  /opt/vmware/server/l​ib/libconf/etc/gtk-2​.0/gdk-pixbuf.loader​s
  /opt/hydra-client/hy​dra_client/task_scri​pts/sync_build.py
  /opt/hydra-client/te​mplates/boot/grub
  /opt/vmware/server/l​ib/libconf/etc/pango​/pango.modules
  /opt/vmware/server/l​ib/libconf/etc/pango​/pangox.aliases
  /opt/vmware/server/l​ib/libconf/etc/gtk-2​.0
  /opt/vmware/server/lib/serverd
  /opt/hydra-client/te​mplates/etc/fstab
  /opt/hydra-client/templates/etc

  Updates for fsvs and a fix for hda (non-RAID)
--------------------​--------------------​--------------------​------------

dev-01 / # fsvs st
.mC. 714 etc/mtab
d... dir etc/fsvs
.mC. 3029 etc/fsvs/6666cd76f96​956469e7be39d750cc7d​9/Ign
.m.. dir etc/fsvs/6666cd76f96​956469e7be39d750cc7d​9
.mC. 779 opt/hydra-client/hyd​ra_client/task_scrip​ts/sync_build.py
.m.? 589 etc/prelink.conf
N... dir .python-eggs
N... 79663
.python-eggs/pysqlit​e-2.4.1-py2.5-linux-​i686.egg-tmp/pysqlit​e2/_sqlite.so
N... dir .python-eggs/pysqlit​e-2.4.1-py2.5-linux-​i686.egg-tmp/pysqlit​e2
N... dir .python-eggs/pysqlit​e-2.4.1-py2.5-linux-​i686.egg-tmp
N... 16528
.python-eggs/simplej​son-1.9.2-py2.5-linu​x-i686.egg-tmp/simpl​ejson/_speedups.so
N... dir
.python-eggs/simplej​son-1.9.2-py2.5-linu​x-i686.egg-tmp/simpl​ejson
N... dir .python-eggs/simplej​son-1.9.2-py2.5-linu​x-i686.egg-tmp
..C. dir .
.m.. dir opt/hydra-client/hyd​ra_client/task_scrip​ts
.m.? 2070 var/cache/edb/mtimedb
.m.. dir var/spool/fsvs
.m.. dir etc
.m.. dir var/cache/edb

The /opt/hydra-client/hy​dra_client/task_scri​pts directory does show as
being "m", but I don't understand why that would mess up the update?

Finally, fwiw, a while back, I submitted a gentoo ebuild (their
equivalent of RPM) to that project (as Gentoo is our OS of choice).
It's an old version (1.1.9), but someone did update it to 1.1.16.
Unfortunately, though, it hasn't yet been accepted into their official
tree. Anyhow, just trying to give a little back.

Thanks again for the help,
Stu

Re: fsvs use case

Author pmarek
Full name P.Marek
Date 2008-08-27 01:44:58 PDT
Message 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://user@svnse​rver//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)!

fsvs use case

Author Stuart Lester <stuart dot lester at gmail dot com>
Full name Stuart Lester <stuart dot lester at gmail dot com>
Date 2008-08-26 10:32:01 PDT
Message Ladies and Gentlemen,
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, 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://user@svnse​rver//home/user/svn/​osrepo to revision
19.
The entry ./etc/fsvs has changed locally

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). 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.

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? Is this an imporper use of this package? Are we missing
something obvious? 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.

Thanks in advance for any insight you can offer,
Stu
Attachments
Messages per page: