gmane.comp.sysutils.backup.fsvs.general

Re: fsvs use case

Philipp Marek — 2008-08-30T07:03:29

Hello Stuart! On Friday 29 August 2008 Stuart Lester wrote: I'm sorry about that. It might have been interesting what "fsvs info " would have said. ... 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. 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. That's understandable. Don't think so. Don't think so, either - my guess is the local entry-list. No. None that I know of. 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 dif

Re: fsvs use case

Stuart Lester — 2008-08-29T19:27:55

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[racallback.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:59:37.704186Z 15:23:28.143 cb___store_prop[racallback.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[racallback.c:292] have name=svn:entry:last-author; user? 0 15:23:28.143 up__parse_prop[update.c:16

Re: fsvs use case

Philipp Marek — 2008-08-29T18:32:20

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

Re: fsvs use case

Stuart Lester — 2008-08-29T15:21:37

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 gmail.com> wrote:

Re: fsvs use case

Stuart Lester — 2008-08-29T13:36:53

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 gmail.com> wrote:

Re: fsvs use case

Stuart Lester — 2008-08-29T13:30:56

That worked...except now I'm seeing the error on files: dev-01 / # fsvs update Updating svn+ssh://user< at >svnserver//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/templates/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-util/fsvs-1.1.16/CONTENTS has changed locally Stu On Fri, Aug 29, 2008 at 5:00 AM, Philipp Marek marek.priv.at> wrote:

Re: fsvs use case

Philipp Marek — 2008-08-29T09:00:47

Hello Stuart! On Thursday 28 August 2008 Stuart Lester wrote: The important line is this: 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) < at >< at > -961,8 +961,10 < at >< at > 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:

Re: fsvs use case

Philipp Marek — 2008-08-28T16:09:01

Hello Stuart, On Thursday 28 August 2008 Stuart Lester wrote: ... So an entry that worked the first time doesn't the second time? Sorry. 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.

Re: fsvs use case

Stuart Lester — 2008-08-28T15:14:47

Phil (and everyone else), We're _still_ getting this error. Here's an example: dev-01 / # fsvs update Updating svn+ssh://user< at >svnserver//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/templates/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..

Re: fsvs use case

Maurice van der Pot — 2008-08-27T18:50:22

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

Re: fsvs use case

Philipp Marek — 2008-08-27T16:05:14

Hello Stuart! On Wednesday 27 August 2008 Stuart Lester wrote: Ok; maybe that's enough to avoid that problem in the future. Me neither. "m" means meta-data - that shouldn't be a conflict. Thank you; maybe they'll take it some time. Regards, Phil

Re: fsvs use case

Stuart Lester — 2008-08-27T14:45:39

Phil et al, On Wed, Aug 27, 2008 at 4:44 AM, Philipp Marek marek.priv.at> wrote: 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< at >svnserver//home/hydra/svn/obx to revision 19. The entry ./opt/hydra-client/hydra_client/task_scripts 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. Definitely a directory. 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. We have ignored all log files, and that doesn't seem to be the problem

Re: fsvs use case

Philipp Marek — 2008-08-27T08:44:58

Hello Stuart! On Tuesday 26 August 2008 Stuart Lester wrote: Yes, that's what FSVS is for. I cannot reproduce that for a directory. And /etc/fsvs shouldn't have changed - possibly the files two levels below. Is that really a file? /etc/fsvs is normally a directory. 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. I'll try :-) No. No. 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 "f

fsvs use case

Stuart Lester — 2008-08-26T17:32:01

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< at >svnserver//home/user/svn/osrepo to revision 19. The entry ./etc/fsvs has changed locally We've tried with and without the "-r ", and we don't always get the same file as having changed (though it is usually one of a handful

Re: changed properties report (group, owner, mode)

Plamen Marinov — 2008-08-26T07:46:26

Hi, Will try. I already have new version. Not sure is it useful, because it is using 'svnadmin dump' (the same output format as 'svn proplist'): $ svnadmin dump --incremental | tr -dc '[:print:]\n' | awk ... > 'incremental-rev2' $ join 'props-rev1' 'incremental-rev2' > 'props-rev2' Old version created each report in 20 minutes. To compare 2 revisions you need to 'diff/join' 2 reports (or 40 minutes). This version, for empty revisions, works very fast (it is incremental). For the largest commit (max number of files, initial commit, ,etc) it takes 2-4 min. Or total 40 minutes for 90 revisions. Plus 'diff/join' 2 reports could be optimized. Instead 'diff/join' props-rev10 and props-rev15 (both full reports). It could be: '(join from incremental-rev11 to incremental-rev15)' and then 'diff/join' with props-rev14 Hope explanation is good. Thanks. First line is 'new', second line is 'old'. So, the same timestamp, group permissions reduced, but sticky added (as I understand, it is safe), SetGID ad

Re: changed properties report (group, owner, mode)

Philipp Marek — 2008-08-24T15:00:52

If you prepare a README (possibly as HTML for easier reading), nicely formatted, with the author's name and email address as well as a license statement, I'll include that in some contrib/ directory in the next release - if you want that. /dev/shm should be a directory, and sticky is ok. A link has no properties, apart from svn:special. It has no mode, no owner and group; if you try a chown on a link, you change the destination it points to. A console gets changed when someone logs in. Maybe ... but why the same timestamp? ... Most of them should be ok - but I didn't look at every one of them. Regards, Phil

Re: changed properties report (group, owner, mode)

Plamen Marinov — 2008-08-23T17:57:26

Hi all, The same scripts attached: Small changes, few bugs fixed, some error handling added. Description ------------------- fsvs-prop-list.sh: execute 'svn proplist' and generate report Output fields:

fsvs-prop-diff.sh: execute fsvs-prop-list.sh and generate two reports, then execute fsvs-prop-file.sh fsvs-prop-file.sh: accept reports from fsvs-prop-list.sh and generate 'diff' report Output fields: #line 1 for first rev parameter, line 2 for second. Eight flags: [ <>=][01][02][03][04][05][06][07] #First flag show: 'time_rev_1 is less or great than time_rev_2'. And seven flags for every column ('0'=not changed) 1234567 1234567

1234567

fsvspropdiff.sh: Execute fsvs-prop-file.sh if you provide two files as command line arguments. Execute fsvs-prop-diff.sh if you pr

Re: questions about "unversion" and "ignore"

Philipp Marek — 2008-08-23T17:56:12

Hello Plamen! Here's another nugget of information. On Wednesday 23 July 2008 MMM MMM wrote: ... The segmentation violation has vanished with current trunk, you said on IRC. And SVN reports *all* properties - whereas FSVS "proplist" only shows not directly interpreted values. FSVS takes the properties that are needed for the filesystem directly; "prop-list" only shows * really user-defined values (like "aaa"="bbb"), and * other things that are not stored in meta-data - like "commit-pipe", etc. Hope that clarifies things a bit. Regards, Phil

changed properties report (group, owner, mode)

Plamen Marinov — 2008-08-23T00:06:50

Hi all, I have all files under version control ('/') and about 100 revisions. I want to check if properties of any file from '/bin' has been changed. Here one simple solution (check attached files): svn output: > $ svn proplist -v -R > Properties on 'file://localhost/media/sda6/backup/fsvs/trunk/base/bin/ntfs-3g': > svn:text-time : 2007-10-08T15:22:05.000000Z > svn:unix-mode : 0755 > svn:owner : 0 root > svn:group : 0 root one line output: > $ fsvs-prop.sh -r head -R > /boot 0777 0 root 0 root > /boot/abi-2.6.22-14-generic 0644 0 root 0 root output changes only: > $ fsvs-prop-diff.sh 1 head -R > /boot > 0755 0 root 0 root > 0777 0 root 0 root ... huh, who changed the permissions :) regards, Plamen. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe< at >fsvs.tigris.org For additional commands, e-mail: users-help< at >fsvs.tigris.org

Re: Feature request for fsvs client (display fsvs properties)

Plamen Marinov — 2008-08-22T14:18:55

Hi all, As I understand: First of all we need 'browse repository'. Some programs have it already. First request - display fsvs properties Some 'repository' commands could be useful for fsvs - info, properties, etc. Second request - diff properties or diff to consider fsvs properties. First, it is my fault, to speak before think. My experience is tortoisesvn and command line svn. Anyway, today decided to take a loot at pysvn and subcommander. Some notes: 1) subcommander I can setup project with repository without working copy. I can select 'repository' and I can see files/directories. I can get 'log' from repository and run 'diff' from 'log' window. (from repository, diff for 'head' and 'previous' is not working) They do not have 'info' command at all. They do not show 'properties' from repository. 2) pysvn (or 'svn-workbench') 2.1) svn project/repository - setup done: fsvs working copy and fsvs repository (check attached file) 'Log', 'Info' and 'Diff' are working fine. 2.2) fsvs project/repository

Re: Feature request for fsvs client (display fsvs properties)

Plamen Marinov — 2008-08-21T18:31:06

Hi, And one more - TortoiseSVN http://groups.google.com/group/tortoisesvn-dev/browse_thread/thread/eda87c8f9a5e9656 regards, Plamen.