P.Marek | 18 Jun 19:56 2009
Picon

[ANNOUNCE] FSVS 1.2.0 released

Hello everybody!

After a long time I'm happy to release a new version.
The delay can be explained by it being incompatible with the older
versions; this is the cause for it being labeled for the new 1.2 series,
although the next big feature (mixed version working copies) is not
included yet.

For the impatient: see
   http://freshmeat.net/projects/fsvs (once it's updated) and
   http://doc.fsvs-software.org/,
but don't complain afterwards ;-)

 About the incompatibilities
=============================

 WAA_CHARS
-----------

FSVS uses (the MD5 of) the absolute pathname as a key for storing internal
data - user-defined properties, a list of block-MD5s for faster change
detection, and things like that.

Now that has a problem if you're (very) unlucky and two of your paths hash
to the same MD5; or if you have nested working copies, eg. "/" and "/etc".
Here all files in the "/etc" working copy get the same internal key as the
ones below "etc" in the "/" working copy, and this will cause problems, as
the FSVS-managed meta-data gets partly changed from two working copies
simultaneously.

(Continue reading)

Gunnar Thielebein | 3 Jun 18:16 2009
Picon
Picon

progress of migration script

Hi all,

Progress of migration script just stalls because of my businness.
At the moment it seems this to be a blocker to the fsvs-1.1.20 release.
Therefore I am looking for some help - best someone with some more 
python experiences than me who can solve the glitches.
Welcome are  also people testing the different steps of the script and 
kick my ass ;-)

Best,
Gunnar

------------------------------------------------------
http://fsvs.tigris.org/ds/viewMessage.do?dsForumId=3928&dsMessageId=2359130

To unsubscribe from this discussion, e-mail: [users-unsubscribe <at> fsvs.tigris.org].

P.Marek | 4 Jun 08:13 2009
Picon

Re: progress of migration script

Hello Gunnar!

> Progress of migration script just stalls because of my businness.
> At the moment it seems this to be a blocker to the fsvs-1.1.20 release.
> Therefore I am looking for some help - best someone with some more
> python experiences than me who can solve the glitches.
> Welcome are  also people testing the different steps of the script and
> kick my ass ;-)
Just this morning I changed the direction a bit ... Most of the conversion will be
avoided and some things done in FSVS itself, as the next version will _only_ be a
1.1.18.

There's only a small bit left to be done in a script - rewriting the ignore lists
(changing the text format), and calling things like "fsvs urls dump | fsvs urls load" to
re-write the lists.
Should be a few lines of perl or python.

Any volunteers for that?

1.2.0 will (AFAIK ATM ;-) have full mixed-working-copy abilities, so that using multiple
URLs from multiple working copies (especially committing!) should *really* work; and,
for compatibilities' sake (with subversion), it will (need to) use a SQLite database.

I'm already half-way there, so the release should happen in this decade.

(Sorry if SQLite gives someone extra troubles; but I need to fetch all entries from a
given URL, and all URLs from a given entry, and doing that with two synchronized on-disk
hashes is much more work than simply using an SQL engine.
There are some other things that'll be put there sooner or later - eg. the properties,
to reduce the number of on-disk files that FSVS uses.)
(Continue reading)

Omar Carvajal | 1 Jun 23:51 2009

FSVS recovery giving me "Out of memory"

Hi All,

I am trying to recover data from a backup I made to an external hard drive using FSVS.

I am issuing the command "fsvs checkout -d . file:///home/disk02/repository/trunk/u" and I get the
following message:

......   3932371  ./s/dsm/versions/emp28118wc/ebc/help/dsmlatam.hlp
17:01:00.157 ops__find_entry_byname[est_ops.c:762] Searching for dsms.hlp (dsms.hlp) found no
entry (ignored_too=0)
17:01:00.157 cb__add_entry[racallback.c:163] entry
s/dsm/versions/emp28118wc/ebc/help/dsms.hlp, mode 0100000; not found, may create
17:01:00.157 ops__allocate[est_ops.c:831] need 1 blocks, freelist=0x3d5fe5f0
17:01:00.157 ops__allocate[est_ops.c:860] splitting block; 12 remain
17:01:00.157 ops__allocate[est_ops.c:886] giving 1 blocks at 0x3d5fefb0
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:entry:committed-rev=2
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:entry:committed-date=2009-04-19T13:06:54.876587Z
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:entry:last-author=root
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:entry:uuid=e6b93b68-2a8e-11de-bc85-4b2b9581cfd7
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:text-time=2007-02-10T19:58:16.000000Z
17:01:00.157 up__parse_prop[update.c:262] marking mtime "2007-02-10T19:58:16.000000Z" to Sat Feb
10 14:58:16 2007
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:unix-mode=0660
17:01:00.157 up__parse_prop[update.c:283] marking mode "0660" to 0660
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:owner=1002 mike
17:01:00.157 cch__hash_find[cache.c:258] looking for 2AD2D = mike
17:01:00.157 up__parse_prop[update.c:199] marking owner 1002 mike to 1002
17:01:00.157 up__parse_prop[update.c:165] got property for dsms.hlp: svn:group=1001 ccigrp
17:01:00.157 cch__hash_find[cache.c:258] looking for 2123A463 = ccigrp
17:01:00.157 up__parse_prop[update.c:230] marking group 1001 ccigrp to 1001
(Continue reading)

Jake P | 27 May 13:51 2009
Picon

FSVS 1.1.16 failing for large binaries over svn+ssh

Has anyone else encountered this problem?

I've successfully set up fsvs on one system with a remote repository that is connected using svn+ssh and
public key certification.

I can check in text files and in fact I was able to backup /etc without any problems.

However, when I try to check in large binaries such as a kernel image from /boot, the checkin does not succeed.

During normal checkin, I get a list of files to be added and then a short message that the commit was
successful.  In the case of a large binary file, the fsvs commit command just stops after encountering this file.

Example:

N...   4723590  /boot/initrd.img-2.6.28-11-server
(process just ends there)

With -d, I get some more information but again the process stops without an error.  Here is the last bit of the output:

11:28:32.363 cs___end_of_block[checksum.c:590] manber found a border: 29406 1B23B5B2 11580000 bec267f381ca1f8dcfdcecafe7ed8562
11:28:32.364 cs___end_of_block[checksum.c:606] on return at fpos=1975006: 11580000 (databits=ff)
11:28:32.364 cs___update_manber[checksum.c:665] block ends after 1975006; size 127195 bytes (border=29406).
11:28:32.364 cs___end_of_block[checksum.c:509] manber reinit
11:28:32.364 cs___end_of_block[checksum.c:606] on return at fpos=1975006: 00000000 (databits= 0)
11:28:32.365 cs___end_of_block[checksum.c:606] on return at fpos=2048000: 77FCFB4F (databits=ff)
11:28:32.365 cs___update_manber[checksum.c:656] block continues after 2048000.

What's weird is that local checkins using a file:/// URL work for the same binary.

------------------------------------------------------
(Continue reading)

Mark J Hewitt | 21 May 20:04 2009
Picon
Picon

FUSE and fsvs

I stopped using fsvs back in the days of 1.1.12 or so because one of the systems on which I was using it acquired a .gvfs FUSE mount point in user home directories.  The semantics of this prevents root from traversing the mount point, so attempting to use fsvs as root on home directories gives you something like:

An error occurred: Permission denied (13)
 in dir__enumerator: lstat(.gvfs)

This is despite every permutation of "ignore" I can think of:

./*/.gvfs/
./**~
./**.tmp
./**.bak
./**.gvfs
./**/.gvfs
./mjh/.gvfs
./*/.gvfs/

So I've tried again with 1.1.17, and the problem still persists.  Looking at the code, the lstat in question will always cause a stop on permission denied.
I was wondering if anyone has a neat workaround for this problem?
P.Marek | 23 Apr 14:29 2009
Picon

Q regarding symlink behaviour

Hello everybody!

I'd like to ask about some behaviour that FSVS should show.

Please assume this directory tree:
   A/
     file
   B/
     file
and a symlink
   C -> A

Now this gets committed, and the "file"s change their data; and the symlink points to B.

What should a
   fsvs ci C/file
do?

1) Give an error, because C is not a directory
2) Commit B/file (and nothing else), because this *target* was chosen
3) Commit C as pointing to B now
4) 2+3 together

I'm not sure what the right behaviour is ... all of these variants have some sunny side.

Any ideas? Opinions?
Thanks in advance.

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=1877834

To unsubscribe from this discussion, e-mail: [users-unsubscribe <at> fsvs.tigris.org].

aluno3 | 6 Mar 19:35 2009
Picon

FSVS from revision 2200 and a few problems and questions

HI

First I want thanks for this program, it is very useful and flexible.

I started use fsvs a few weeks ago but I identify a few problems.I have
my project (about 10GB files) on server with svn repository and this
repository is used by a few computers programmers.

Questions:

1.How can  I add files and directories recursive? (sometimes I must
commit about hundreds files and directory). I always  do 'find ./ |xargs
fsvs add' but is it sole solution (with use external binary) ?

This solution has problem with files which are in repository:

bash-3.1# ls
init.d  inittab  ssh
bash-3.1# fsvs st
bash-3.1# touch testfile
bash-3.1# fsvs st
N...         0  testfile
.mC.       dir  .
bash-3.1# find ./|xargs fsvs add
N...         0  ./testfile
n...      1591  ./init.d/development
n...      1006  ./init.d/devel.sh
n...      1677  ./init.d/kostkaexport
n...       dir  ./init.d
n...      2020  ./inittab
n...       839  ./ssh/sshd_config_devel
n...       405  ./ssh/ssh_known_hosts
n...       dir  ./ssh
bash-3.1# fsvs ci

An error occurred: RA layer request failed (175002)
  in ci__directory: add_directory("./etc", source="(null)" <at> HEAD): Server sent unexpected return
value (405 Method Not Allowed) in responseto MKCOL request for '/repository/etc'

I know that I add files which are in repository but what can I do with
this files? When I made this mistake (add files to repository which are
in repository) I run fsvs sync-repos and this work correctly but my
repository has 10GB and this operation continues about 20 minutes.

When I try this in svn client I get:

bash-3.1# svn add ./testfile
svn: warning: 'testfile' is already under version control

Problems:

1.When I try do fsvs up with specified revision I get segmentation fault:

bash-3.1# fsvs up -r 12311
Segmentation fault

bash-3.1# fsvs up -r 12311 -d

6:13:14.270 up__parse_prop[update.c:161] got property for etc:
svn:entry:committed-date=2009-02-12T14:00:04.411850Z
16:13:14.270 cb___store_prop[racallback.c:311] have
name=svn:entry:committed-date; user? 0
16:13:14.270 hlp___do_convert[helper.c:148] before iconv
from=svn:entry:last-author
16:13:14.270 hlp___do_convert[helper.c:155] after iconv
to=svn:entry:last-author ret=0
16:13:14.270 hlp___do_convert[helper.c:185] converted
svn:entry:last-author to svn:entry:last-author
16:13:14.270 hlp___do_convert[helper.c:148] before iconv from=user
16:13:14.270 hlp___do_convert[helper.c:155] after iconv to=user ret=0
16:13:14.270 hlp___do_convert[helper.c:185] converted user to
apiechocki
16:13:14.270 up__parse_prop[update.c:161] got property for etc:
svn:entry:last-author=user
16:13:14.270 cb___store_prop[racallback.c:311] have
name=svn:entry:last-author; user? 0
16:13:14.270 hlp___do_convert[helper.c:148] before iconv from=svn:entry:uuid
16:13:14.270 hlp___do_convert[helper.c:155] after iconv
to=svn:entry:uuid ret=0
16:13:14.270 hlp___do_convert[helper.c:185] converted svn:entry:uuid to
svn:entry:uuid
16:13:14.270 hlp___do_convert[helper.c:148] before iconv
from=7703f7ce-9b10-0410-893c-be4a98d5aa3d
16:13:14.270 hlp___do_convert[helper.c:155] after iconv
to=7703f7ce-9b10-0410-893c-be4a98d5aa3d ret=0
16:13:14.270 hlp___do_convert[helper.c:185] converted
7703f7ce-9b10-0410-893c-be4a98d5aa3d to 7703f7ce-9b10-0410-893c-be4a98d5aa3d
16:13:14.270 up__parse_prop[update.c:161] got property for etc:
svn:entry:uuid=7703f7ce-9b10-0410-893c-be4a98d5aa3d
16:13:14.270 cb___store_prop[racallback.c:311] have name=svn:entry:uuid;
user? 0
16:13:14.270 hlp___do_convert[helper.c:148] before iconv from=svn:text-time
16:13:14.270 hlp___do_convert[helper.c:155] after iconv to=svn:text-time
ret=0
16:13:14.270 hlp___do_convert[helper.c:185] converted svn:text-time to
svn:text-time
16:13:14.270 up__parse_prop[update.c:153] got NULL property for etc:
svn:text-time
Segmentation fault

2.When I try fsvs status (which some changes) I sometimes get
segmentation fault:

bash-3.1# fsvs
st                                                                     
.....
.....
D...      2195  usr/local/include/atalk/compat.h
D...      3159  usr/local/include/atalk/asp.h
D...      5979  usr/local/include/atalk/atp.h
D...      6195  usr/local/include/atalk/unicode.h
19:22:03.150 st__status[status.c:275] INTERNAL BUG
  sts->was_output
  ./usr/local/include was already output ...
Segmentation fault

bash-3.1# fsvs st -d

....

19:31:33.610 ops__update_single_entry[est_ops.c:1392] known
./usr/local/include/atalk/unicode.h: action=2, flags=0, mode=0100644,
status=0
19:31:33.610 ops__update_filter_set_bits[est_ops.c:1470] filter says 1
19:31:33.610 ops__build_path[est_ops.c:694] 0xf7358bfc found in cache
index 13; lru 13
19:31:33.610 hlp__format_path[helper.c:1600] parent=., has ; len=0,
rel_len=49
D...      6195  usr/local/include/atalk/unicode.h
19:31:33.610 waa__update_tree[waa.c:2123] checking parent atalk/unicode.h
19:31:33.610 waa___finish_directory[waa.c:1901] checking directory
atalk: 0 unfini, 25 of 25 (removed, child)
19:31:33.610 waa___finish_directory[waa.c:1915] walker=atalk;
status=removed, child
19:31:33.610 waa___finish_directory[waa.c:1946] include has a finished
child, now 0 unfinished
19:31:33.610 waa___finish_directory[waa.c:1901] checking directory
include: 0 unfini, 2 of 2 (changed, mtime, child)
19:31:33.610 waa___finish_directory[waa.c:1915] walker=include;
status=changed, mtime, child
19:31:33.610 waa___check_dir_for_update[waa.c:1864] dir_to_print | CHECK
for include
19:31:33.610 ops__build_path[est_ops.c:694] 0xf7316020 found in cache
index 36; lru 13
19:31:33.610 waa__update_dir[waa.c:1458] update_dir:
chdir(./base/xarch.lzm/usr/local/include)
19:31:33.610 hlp__lstat[helper.c:354] .: uid=0 gid=0 mode=040755
dev=0x812 ino=1195229 rdev=0x0 size=4096
19:31:33.610 waa__dir_enum[waa.c:2782] checking: 1195229 to 913990
19:31:33.610 dir__enumerator[direnum.c:462] found 1195229 .
19:31:33.610 dir__enumerator[direnum.c:462] found 1194450 ..
19:31:33.610 dir__enumerator[direnum.c:518] after loop found 0 entries,
0 bytes string-space
19:31:33.610 waa__update_dir[waa.c:1469] update_dir: direnum found 0;
old has 2 (0)
19:31:33.610 waa__update_dir[waa.c:1592] update_dir reports 0 new found,
status 0
19:31:33.610 st__status[status.c:275] INTERNAL BUG
  sts->was_output
  ./usr/local/include was already output ..

------------------------------------------------------
http://fsvs.tigris.org/ds/viewMessage.do?dsForumId=3928&dsMessageId=1278430

To unsubscribe from this discussion, e-mail: [users-unsubscribe <at> fsvs.tigris.org].

Gunnar Thielebein | 27 Feb 13:31 2009
Picon
Picon

apt-hook / fsvs commit message size

Hi all,

i have written a new version of fsvs-apt-hook for debian based systems.
This will now reuse the information written to apt/term.log and using
all lines "Setting up" / "Removing" / "Purge"
for the commit message. Unfortunately I havent found a way yet to get
the information about the commandline issued
but this is only minor.
What me bothers now is that when the list of installed packages is
really long I get error message:

> An error occurred: RA layer request failed (175002)
>   in ci__work: svn_ra_get_commit_editor: applying log message to
> //!svn/wbl/6ff1bf23-b789-46fe-b398-debf02dea90e/117: 400 Bad Request
> (https://fsvsp01.core.local)
This seems a problem with the commit message.
What is the maximum size of the commit message I can use for checkins?

Attached you can find current version of script.

------------------------------------------------------
http://fsvs.tigris.org/ds/viewMessage.do?dsForumId=3928&dsMessageId=1238594

To unsubscribe from this discussion, e-mail: [users-unsubscribe <at> fsvs.tigris.org].
Attachment (fsvs-apt-hook.py): text/x-python, 2425 bytes
Peter Rabbitson | 25 Feb 16:00 2009
Picon

Unexplicable -C behavior

xxx:/# fsvs status -C
.mC.       600  etc/group
.mC.      1188  etc/passwd

xxx:/# fsvs status -CC
<no output>

my config:
filter=text,new,deleted,group,owner
empty_commit=no

My goal was to somehow add the -CC to config, but the problem
above is a showstopper (apart from config not taking checksum
apparently)

Thanks

------------------------------------------------------
http://fsvs.tigris.org/ds/viewMessage.do?dsForumId=3928&dsMessageId=1227154

To unsubscribe from this discussion, e-mail: [users-unsubscribe <at> fsvs.tigris.org].

Mmm Mmm | 24 Feb 19:13 2009
Picon

howto: two url with two WC? (ignores per url?)

Hi,

How to have two urls with two working copies?

 From fsvs docs, I understand that I have to commit using command line 
parameters. Example:
fsvs commit -u 'url1' /dir001 /dir002 ... /dir099
fsvs commit -u 'url2' /dir101 /dir102 ... /dir199

I have few questions, please:

1) do we have ignore (and take) patterns per url?

2) If I ignore all url2 dirs: /dir101 /dir102 ... /dir199
Commit to url1 will become very simple:
fsvs commit -u 'url1' /
What about commit to url2? Will it work? All dirs are already ignored:
fsvs commit -u 'url2' /dir101 /dir102 /dir199

3) Having 99 dirs as command line parameter is not nice. Fsvs  ignore 
load, is much better:
$ cat ignore1 | fsvs ignore load; fsvs commit -u url1 /
$ cat ignore2 | fsvs ignore load; fsvs commit -u url2 /

Is it a good solution? Will it works always: sync-repos, commit, update, 
revert...?

4) is there better solution, for example using FSVS_CONF?

5) what if the case is more complicated:
fsvs commit -u 'url1' /dir1/url1 /dir2/url1
fsvs commit -u 'url2' /dir1/url2 /dir2/url2

In this case:
- Both dirs (dir1 and dir2) will be commited to both urls: url1 and url2.
- if I commit to url1, it will commit meta data of both dirs: dir1 and dir2.
- if I update from url1 (or url2), it will update the meta data of both 
dirs: dir1 and dir2.

<<...in case the same entry is in more than one. *(Which is *not* 
recommended!)*>>
What is the answer?
Nested working copies not supported?
Or
Having a directory meta data in both urls is NOT critical (not 
recomended, but possible)?

Please, give me some hints, example or point me to the right docs.
Thank you.

------------------------------------------------------
http://fsvs.tigris.org/ds/viewMessage.do?dsForumId=3928&dsMessageId=1221771

To unsubscribe from this discussion, e-mail: [users-unsubscribe <at> fsvs.tigris.org].


Gmane