[ANNOUNCE] FSVS 1.1.17 released
Hello everybody, it's finally time to announce a new version. There have been a lot of internal changes (again); and that did take most of the time, because I had to shatter many hours of thinking into many small half-hour pieces, and that means a lot of wasted time. I hope to put the next version out sooner; it should have more user-visible (and fewer internal) changes. And that's already the keyword - the next version will feature some incompatibilities, and will duly be noted 1.2.0, or even 2.0. Time (and the next release announcement) will tell. Well, back to more mundane matters - what did change since 1.1.16? There are some additional features: - New uncopy command, to disambiguate revert on copied and changed entries. Manually added or prop-set entries are kept known. - New option all_removed, to trim the output for deleted hierarchies. - New option config_dir, important for https connections with client certificate authentication. - New command delay, for use in scripts. - New command rel-ignore; this converts the given ($PWD-local) shell patterns to working copy root relative. - New fsvs cat command, to fetch really pristine copies from the repository. - A new flag for ignore patterns, for matching directories only. - And a way for ignore patterns to match the entries' mode; so eg. world-unreadable files can easily be ignored. The most important fixes are: - Bugfix for filtered commit (eg. -f text). Previously that stored the current meta-data of entries that didn't match the filter in the entry list, too; so they wouldn't be seen as changed afterwards. - Performance fix for fsvs diff -rX:Y entry - don't diff the whole working copy, only the given entries. - diff showed for replaced entries only in rX - fixed. - Bugfix for dir_sort option; the root directory wasn't printed. - Bugfixes for memory and file leaks in /tmp. Regarding documentation and directly user-visible changes there are - Some documentation fixes, and repairs for the man pages. There's now a bit more included in the source distribution, too. - Started a tips tricks document. - User-readable error on non-writeable $FSVS_CONF. - The option dir_sort now uses strcoll(), ie. sorts according to the current locale. - fsvs info for the working copy root now prints the revision of the highest priority URL, and not 0. Not directly related to FSVS, but maybe of interest for users: there's a new web site http://doc.fsvs-software.org;, which has the (generated) documentation available as normal files on a web server - and doesn't use the (slow) checkout hierarchy of fsvs.tigris.org. Last, but not least, I did some small enhancements that should make life easier for some corner-cases: - Export some environment variables for use in diff, commit- and update-pipes. - Splitted -C into finer grained option settings -o change_check. Changed the default to use MD5 on possibly-changed files. - FSVS now shows maybe changed for unreadable files or directories; should we throw a warning? - Some directory mtime handling fixes. - Another try to detect invalid colordiff program names, and a better message than a simple EPIPE. I'd like to say thank you for the users that reported problems; in (arbitrarily alphabetic order) Maurice, Plamen, and Thomas. *** Thank you! *** You can get it on the usual place: http://freshmeat.net/projects/fsvs/; some distributions will have packages for you. every kind of feedback is highly appreciated, be it bug reports, questions, ideas or even patches; please send it to the [EMAIL PROTECTED] or the [EMAIL PROTECTED] mailing list, as appropriate. If you create packages for $DISTRIBUTION (and want to share them), please tell me (and possibly the users-list), so that I can put the links on the download page. [ BTW, if you provide some easy way to use FSVS for eg. /etc, you might want to take a look at the example tree in the source distribution. ] To avoid angry (or curious) questions, I'll add what I'd like to see in the next version - and why that'll make FSVS incompatible with 1.1.x (and 1.0.x, of course). - The WAA and CONF layout will change a bit: - The URL list will move to the WAA. - The filename hashing may currently produce collisions, if you're using nested working copies. - I'm planning to enhance the (current) ignore patterns to groupings, which would also serve to provide svn's auto-props feature. Then world-unreadable entries can be ignored, or can be sent encrypted to the repository. That'll (possibly) mean a bit of change in the way ignore patterns are stored in $FSVS_CONF; maybe I can do that compatible. Then there are lots of other features I'd like to implement - but I think that these would be enough for a new version. Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)! - To
Re: [feature request] auto unversion of files matching new ignore pattern
Hello Gunnar! On Tuesday 30 September 2008 Gunnar Thielebein wrote: It would be nice if fsvs would have an option that if patterns are edited files that are matched also automagically become unversioned. If I have added some pattern like ./etc/gshadow- It should automaticly appear as unversioned: .d.. ./etc/gshadow- IMO this was already requested some time ago. I think adding a config for that would also not break too much compatibility of older versions. Yes, it would have to be some config option, because that would mean trying *all* patterns on *all* known entries ... and that can take some time, and possibly include entries that you want to keep. It is that you cant have the ultimate ignore list matching all kind of distribution. Easing the use of the unversion would help in customising hosts. Yes, that's right ... Maybe the inverse - doing unversion with some flag puts a take-pattern in front of the list? But the shell expands wildcards, whereas FSVS doesn't ... so you'd get a whole lot of take-patterns. At the moment I need to edit the ignore list, then unversion the files and if some other admin has done work also remember the pathes i removed. What do you think about that? Well, since some time I've got a point on my TODO ... fsvs shelf and unshelf or something like that. That should mark all local changes as not-changed, so that only new changes appear (and get committed) - and on unshelf they get visible again. But that should work in multiple layers, and possibly many changes in a single file should be splitted into the various shelves, etc. Kind of what quilt does: http://savannah.nongnu.org/projects/quilt But I have no real idea how that can be sanely implemented. Currently I'd like to keep that behaviour as-is - trying a hundred patterns against some hundred thousand paths isn't nice. But if you really insist, we can discuss further which solution you could implement ;-) 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]
Re: Pointer arithmetic in src/direnum.c:561
Hello Jonty! On Thursday 18 September 2008 Jon wrote: I think line src/direnum.c:561 should change from: sts-name=names[i] + this-strings; to: sts-name=this-strings + names[i]; ... I think it generates bad code when the source expression is int+char*. Yes, you're right. It's a bit cleaner that way. Fixed in r1882. Thank you! 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]
Re: [PATCH] - Client certificate authentication
On Monday 01 September 2008 Gunnar Thielebein wrote: sorry that it took time until i could made a test (finished a move and have no internet connection in my flat yet). No problem. I did a test with 1873 (1865 failed for some reason). When changing the config_dir option to e.g. /root/.subversion fsvs does not recognise this and still keeps the default path /etc/fsvs/auth. My configfile looks this: author=$SUDO_USER config_dir=/root/.subversion If you need further information please let me know. Thank you, I'll take a look. 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]
[PATCH] - Client certificate authentication
Hello Gunnar,
could you please test that this works for you? It's already committed in
r1865, so if you're on HEAD you won't need that.
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
Index: src/options.h
===
--- src/options.h (Revision 1864)
+++ src/options.h (Arbeitskopie)
@@ -105,6 +105,9 @@ enum opt__settings_e {
/** The base path of the configuration area.
* See \ref o_conf. */
OPT__CONF_PATH,
+ /** The config directory to use.
+ * See \ref o_configdir. */
+ OPT__CONFIG_DIR,
/** End of enum marker. */
OPT__COUNT
Index: src/interface.h
===
--- src/interface.h (Revision 1864)
+++ src/interface.h (Arbeitskopie)
@@ -43,6 +43,9 @@
#define DEFAULT_WAA_PATH /var/spool/fsvs
/** The default CONF path. */
#define DEFAULT_CONF_PATH /etc/fsvs
+/** The default config directory (for authentication data),
+ * relative to $FSVS_CONF. */
+#define DEFAULT_CONFIGDIR_SUB /auth/
/** \name List of environment variables used for a chroot jail.
Index: src/waa.c
===
--- src/waa.c (Revision 1864)
+++ src/waa.c (Arbeitskopie)
@@ -158,6 +158,8 @@ inline void waa___init_path(enum opt__se
int waa__init(void)
{
int status;
+ char *cp;
+ int len;
status=0;
@@ -245,6 +247,21 @@ int waa__init(void)
opt__set_int( OPT__SOFTROOT, PRIO_MUSTHAVE,
opt__get_int(OPT__SOFTROOT));
+
+ if (opt__get_int(OPT__CONFIG_DIR)==0)
+ {
+ len=opt__get_int(OPT__CONF_PATH)+strlen(DEFAULT_CONFIGDIR_SUB)+1;
+
+ cp=malloc(len);
+ STOPIF_ENOMEM(!cp);
+
+ strcpy(cp, opt__get_string(OPT__CONF_PATH));
+ strcat(cp, DEFAULT_CONFIGDIR_SUB);
+
+ opt__set_string(OPT__CONFIG_DIR, PRIO_MUSTHAVE, cp);
+ opt__set_int(OPT__CONFIG_DIR, PRIO_MUSTHAVE, len-1);
+ }
+
ex:
return status;
}
Index: src/dox/options.dox
===
--- src/dox/options.dox (Revision 1864)
+++ src/dox/options.dox (Arbeitskopie)
@@ -17,6 +17,7 @@ FSVS currently knows:UL
LI\c commit_to - \ref o_commit_to
LI\c conflict - \ref o_conflict
LI\c conf - \ref o_conf.
+LI\c config_dir - \ref o_configdir.
LI\c copyfrom_exp - \ref o_copyfrom_exp
LI\c debug_output - \ref o_debug_output
LI\c delay - \ref o_delay
@@ -584,5 +585,20 @@ howto_backup_recovery for further discus
variables (\c $FSVS_CONF resp. \c $FSVS_WAA) or as command line parameter;
settings in config files are ignored.
+
+\section o_configdir Configuration directory for the subversion libraries
+
+This path specifies where the subversion libraries should take their
+configuration data from; the most important aspect of that is authentication
+data, especially for certificate authentication.
+
+The default value is \c $FSVS_CONF/auth/.
+
+\c /etc/fsvs/config could have eg.
+\code
+ config_dir=/root/.subversion
+\endcode
+
+
*/
// vi: filetype=doxygen spell spelllang=en_gb formatoptions+=ta :
Index: src/racallback.c
===
--- src/racallback.c (Revision 1864)
+++ src/racallback.c (Arbeitskopie)
@@ -18,7 +18,6 @@
#include subversion-1/svn_ra.h
#include subversion-1/svn_auth.h
#include subversion-1/svn_client.h
-#include subversion-1/svn_config.h
#include subversion-1/svn_cmdline.h
@@ -41,13 +40,12 @@ svn_error_t *cb__init(apr_pool_t *pool)
svn_config_t *cfg;
- status=0;
- STOPIF_SVNERR(svn_config_get_config,
- (cfg_hash, NULL, pool) );
+ STOPIF( hlp__get_svn_config(cfg_hash), NULL);
cfg = apr_hash_get(cfg_hash, SVN_CONFIG_CATEGORY_CONFIG,
APR_HASH_KEY_STRING);
+
/* Set up Authentication stuff. */
STOPIF_SVNERR( svn_cmdline_setup_auth_baton,
(cb__cb_table.auth_baton,
@@ -55,8 +53,8 @@ svn_error_t *cb__init(apr_pool_t *pool)
opt__get_int(OPT__AUTHOR) ?
opt__get_string(OPT__AUTHOR) : NULL,
NULL, /* Password */
- NULL, /* Config dir */
- 1, /* no_auth_cache */
+ opt__get_string(OPT__CONFIG_DIR),
+ 0, /* no_auth_cache */
cfg,
NULL, /* cancel function */
NULL, /* cancel baton */
Index: src/url.c
===
--- src/url.c (Revision 1864)
+++ src/url.c (Arbeitskopie)
@@ -12,6 +12,7 @@
#include ctype.h
#include sys/select.h
+
#include url.h
#include waa.h
#include cache.h
@@ -868,6 +869,8 @@ int url__open_session(svn_ra_session_t *
{
int status;
svn_error_t *status_svn;
+ apr_hash_t *cfg;
+
status=0;
if (!current_url-pool)
@@ -877,13 +880,15 @@ int url__open_session(svn_ra_session_t *
no pool);
}
+ STOPIF( hlp__get_svn_config(cfg), NULL);
+
/** Try svn_ra_reparent() */
if (!current_url-session)
{
STOPIF_SVNERR_EXTRA( svn_ra_open,
( current_url-session, current_url-url,
cb__cb_table, NULL, /* cbtable, cbbaton, */
- NULL, /* config hash
[ANNOUNCE] FSVS 1.1.16 released, and [Alert]
Hello everybody, here's a fresh release. Important: if you're versioning your /etc/ *and* you're using the DynDNS registration client, please change your password; the filtering script used for ddclient.conf was wrong, and so your password might be stored in your repository. It's been about 3 months since the last feature release; it took a bit longer because I changed some internal conventions and shoved code around. The major changes since 1.1.15 are: - FSVS_WARNINGS removed. Use FSVS_WARNING. - Handling of FSVS_WAA and FSVS_CONF now via the normal option handling, to reduce code size. Now it's possible to use -oconf=... on the command line, too. (But it's not possible to override the paths from the config file.) - Bugfix for error after commit, when $EDITOR returned an 0 byte file as commit message. - fsvs diff changed to recursive behavior, as svn does. - Fixed fsvs diff -rX to print only changed entries, not the whole list. - fsvs diff -rX:Y reimplemented, too; performance could get optimized. - Rewrote entry fetching from the repository. Previously a file with bad mode (like 0111) couldn't get diffed. - update -rX and diff -rX (but not diff -rX:Y) now use the per-url override syntax (see -u). - New option to set maximum number of revisions on fsvs log. - Fixed diff for symlinks and devices. - New option stop_change for use in scripts. - New option author for commit (but that doesn't work for svn+ssh://) - Changed from merge to diff3 as merge program; seems to be more common. - Committed the distclean patch from Sheldon Hearn. - make install implemented. For the full list please see http://fsvs.tigris.org/source/browse/fsvs/tags/fsvs-1.1.16/fsvs/CHANGES?rev=1774view=markup There are some known issues, too: - Multi-URL code has been found to be not perfect - removing a (common) directory removes files from all URLs. - fsvs sync now tries to fetch all file sizes and entry types from the repository, too. For that we have to do a recursive listing, and fetch special entries; encoded files with only a few kB are looked at, too. Needs more time and bandwidth. - fsvs revert -rX still doesn't work if types of entries would get changed (dir - file, symlink - device, etc.) - that's next on the list. For this release diff was done, and I hope it works better. So there's still some work left; stay tuned :-) Please fetch the sources from http://freshmeat.net/projects/fsvs/, or ask your distributions for packages - at least for debian and fedora you should be fine. If there are any questions, problems or suchlike, don't hesitate to ask on the mailing lists. 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]
Re: fsvs in Fedora
Hello David! On Wednesday 04 June 2008 David Fraser wrote: Just wanted to say thanks for writing fsvs - been waiting for something like this for years. You're welcome - and welcome to FSVS :-) I've got fsvs included in Fedora - 1.1.15 is now in the repositories for Fedora 7 and upwards, and I'm the package maintainer. Thank you; I'll mention that on the webpages. I presume the announcements mailing list is the place to lurk to look for new releases - but there didn't seem to be a notice of the release of 1.1.15... That's because 1.1.15 had just a single script changed (vs. 1.1.14) - it was a security update, and all three mailing lists got an alert. Well, welcome on board, I sure hope you enjoy the journey! 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]
Re: bugreport: fsvs update looses attributes
Hello Shuvaev! Thank you for your email. On Friday 23 May 2008 Nast wrote: I have got bug in fsvs then I try to execute fsvs update ... as you can see file size is 20 bytes and mdate is right too, but look at the permissions was 644, but now it changed to 600. Why? I think I already got it fixed; are you in a hurry, or can you wait for 2 - 3 weeks for the next release? 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]
Re: bugreport: fsvs diff
Hello Shuvaev! On Friday 23 May 2008 Nast wrote: I'd like to inform you about bug in fsvs (FSVS (licensed under the GPLv3), (C) by Ph. Marek; version fsvs-1.1.14:1496) under Debian Linux 4.0 (etch) This bug appears when I try to get differense between 2 revisions: ... This error occurs every time I try to merge 2 revisions in repository which contain symlinks to any files. As far as I understand command diff -rN:N+M can't work with symlinks. When I try to make diff using something like ... I hope my message will help you to resolve this bug. If you need any other information, mail me at [EMAIL PROTECTED] Yes, you're right. fsvs diff -rX:Y is broken. I already completely rewrote it - to solve other problems - but this one is new. Thank you for reporting. I added this case to my test list -- let's hope for the best in the next release :-) 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]
Re: FSVS 1.1.14 and up and CentOS 4.4: Error on make run-tests
Hello Ben, On Wednesday 07 May 2008 Benjamin M. wrote: Philipp Marek wrote, On 06/05/08 03:33: Do you have an immediate need to get a newer FSVS running, or could you wait for the next release (planned in 2 weeks, will probably be 3 or 4 weeks :( )? Take all the time you need ... no hurry here and don't hesitate if you want me to test patches. thank you ... I'll come back to you. 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]
Re: FSVS 1.1.14 and up and CentOS 4.4: Error on make run-tests
Hello Ben! On Friday 02 May 2008 Benjamin M. wrote: For run-tests: After updating to r1659 everything is just working great... except for some run-tests failing ... ;-) Great, so the build problems are sorted out. I'll yet have to find and fix some bugs - some tests fail for me, too. But then again ... /usr/src/fsvs-trunk-3/tests/090_special: line 89: syntax error near unexpected token `$a/$b/file' That I don't understand ... Do you have an immediate need to get a newer FSVS running, or could you wait for the next release (planned in 2 weeks, will probably be 3 or 4 weeks :( )? 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]
Re: FSVS 1.1.12 and up: --enable-debug - VALGRIND_MAKE_MEM_DEFINED / VALGRIND_MAKE_MEM_NOACCESS
Hello Ben, On Thursday 01 May 2008 Benjamin M. wrote: With version 1.1.12 and up (no problem with previous versions) I have the following error when using ./configure --enable-debug $ make Link fsvs est_ops.o(.text+0xf85): In function `ops__allocate': /usr/src/fsvs-1.1.12/src/est_ops.c:820: undefined reference to `VALGRIND_MAKE_MEM_DEFINED' Could you please send me your config.h? Thank you. -- 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]
Re: FSVS 1.1.7 and up: apr_md5.h: No such file or directory (CentOS 5)
Hello Ben! On Thursday 01 May 2008 Benjamin M. wrote: After completely reinstalling apr/apr-util no more configure error. Oh well... Ok. But looking at that below I don't think that all apr problems are resolved yet. Attached some run-tests errors under CentOS 5 with r1658 (trunk). In some cases I (can) have to delete /tmp/fsvs-test-0 to reproduce the errors.. Otherwise I will try to find out what going wrong under CentOS 4.4. fsvs compiles with some warnings but I get weird errors on make run-tests . It perhaps related to recent subversion updates ... Short question - have you thought about going the easy way and just using the chroot helper and a chroot environment? I know that it's not the best solution - but I'm using that on some machines that I can't update (because they're still running linux 2.4), and it works ... http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__howto__chroot.html If you like I could send you a debian-based chroot (or I could put it for download even), so most of the work would be done ... You'd only have to compile the chrooter itself. I'm using i686 and amd64 - is that enough for you? If not I could take a look which packages the files are from - then you could simply extract the needed packages from debian, and be done ... In file included from /usr/local/apr-1.2.12/include/apr-1/apr_file_io.h:29, from global.h:20, from ac_list.c:9: /usr/local/apr-1.2.12/include/apr-1/apr_file_info.h:200: error: expected specifier-qualifier-list before ‘apr_ino_t’ ... This sounds like an apr install problem again - apr_file_info.h gives an error. It seems that apr_ino_t is not defined. I have it in /usr/include/apr-1.0/apr.h:275; maybe one of the #ifdef goes wrong for you? Trunk under CentOS 4.4 CC ac_list.c In file included from ac_list.c:27: resolve.h:20: warning: `sentinel' attribute directive ignored These can be ignored. options.c: In function `opt__load_settings': options.c:428: warning: 'status' might be used uninitialized in this function Thank you! r1659. $ make run-tests make -C ../tests BINARY=/usr/src/fsvs-trunk-2/src/fsvs Preparing default repository. make[5]: *** [prepare_wc] Error 1 make[5]: *** [prepare_wc] Error 1 make[4]: *** [prepare_wcs] Error 2 make[3]: *** [prepare_clean] Error 2 make[2]: *** [/tmp/fsvs-test-0/default-repos.dump] Error 2 make[1]: *** [run-tests] Error 2 make: *** [run-tests] Error 2 I'd assume that means that prepare_wc gives an error - but why? Please try this: touch /tmp/fsvs-test-0/default-repos.dump make run-tests TEST_LIST=001* VERBOSE=1 -- 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]
Re: FSVS 1.1.14 and up and CentOS 4.4: Error on make run-tests
On Thursday 01 May 2008 Benjamin M. wrote: Phil, With versions 1.1.14 and up (no problem with previous versions) and CentOS 4.4 (no problem with CentOS 5) I have the following error on $ make run-tests ... + make -s -C /usr/src/fsvs-1.1.14/tests prepare_clean make[5]: *** [prepare_wc] Error 1 make[5]: *** [prepare_wc] Error 1 make[4]: *** [prepare_wcs] Error 2 make[3]: *** [prepare_clean] Error 2 ++ /usr/src/fsvs-1.1.14/tests/001_init_dir failed ++ make[2]: *** [run_tests] Error 1 make[1]: *** [run-tests] Error 2 make: *** [run-tests] Error 2 Please change all make -s in tests/Makefile into make VERBOSE=1, so that we see some output, and send me the output of make run-tests TEST_LIST=001* VERBOSE=1. Thank you! -- 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]
Re: FSVS 1.1.12 and up: --enable-debug - VALGRIND_MAKE_MEM_DEFINED / VALGRIND_MAKE_MEM_NOACCESS
On Friday 02 May 2008 Benjamin M. wrote: From 1.1.12. with ./configure --enable-debug ... /** Whether the valgrind headers were found. * Then some initializers can specifically mark areas as initialized. */ #define HAVE_VALGRIND 1 So the valgrind header was found - only it doesn't contain what we expect. Are you using an older version than 3.3? I know that I had to change something a few months ago ... don't remember whether that was for 3.0, 3.3 or something inbetween. Please change this line to #undef HAVE_VALGRIND and recompile. 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]
Re: FSVS 1.1.7 and up: apr_md5.h: No such file or directory (CentOS 5)
Hello Benjamin! On Thursday 01 May 2008 Benjamin M. wrote: ... $ /usr/local/apr/bin/apr-1-config --includedir /usr/local/apr-1.2.12/include/apr-1 So your apr installation says that this directory has the header files; that's what's written in the Makefile, too: CFLAGS := -g -O2 ... -idirafter /usr/local/apr-1.2.12/include/apr-1 Why does your apr installation lie to you? You've got the header files in /usr/local/apr-util-1.2.12/include/apr-1/apr_md5.h - that's too deep, by the two levels include/apr-1. If I do the same for debian I get # apr-1-config --includedir /usr/include/apr-1.0 # ls /usr/include/apr-1.0/ apr_allocator.h apr_file_info.h apr_ldap_init.h ... But I see: you said $ which apr-1-config /usr/local/bin/apr-1-config ie. your apr-1-config is found in $PATH in /usr/local/bin, but you ask another instance: $ /usr/local/apr/bin/apr-1-config --includedir /usr/local/apr-1.2.12/include/apr-1 You've got more than a single installation of apr - and that seems to give you the problems. Probably one installation removed the old include headers, but put its apr-1-config in a later directory in $PATH - so the wrong one is called, with stale data. Maybe you could try using the --with-aprinc parameter for ./configure. I've tried and it doesn't change anything... The given value should override anything found by apr-config. Did you give --with-aprinc=/usr/local/apr-util-1.2.12/include/apr-1/apr_md5.h to configure? If that all fails, just change the line in the Makefile (correct path) - then it should compile. BTW: Why are you using 1.1.7 and nothing current? 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]
[ALERT] Bug in example setup - passwords not removed from /etc/shadow
Hello everybody, since 1.1.13 the FSVS sources included an example directory, with some scripts in int. I just found out that I forgot to put the correct script in my subversion source directories; the example script for removing passwords in /etc/shadow and /etc/gshadow was wrong, and didn't remove them. Please see here for a quick download of a fixed version: http://fsvs.tigris.org/source/browse/fsvs/trunk/fsvs/example/var/lib/fsvs-versioning/scripts/shadow-clean.pl?rev=1612view=log Please take all necessary steps: - Install the fixed script; and either - change all passwords on your system or, if that's not possible, - use svndumpfilter to remove old versions of your shadow and gshadow files, or, - if you can restart versioning /etc, remove the repository, re-create it, and use fsvs sync to tell FSVS that there's nothing stored. I've put an message on freshmeat, too. I apologize for the inconvinience. 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]
[ANNOUNCE] FSVS 1.1.14 released
Hello everybody, FSVS 1.1.14 is released, with a few new features and some bugfixes. There are some fixes I wanted to get into this version (diff output and behaviour, revert to a revision) but didn't make it - I'd need a few uninterrupted hours to think that through, and that just doesn't work in the train. So, to not cause endless delays, I'm releasing 1.1.14 now - and try really hard to find the time. New features: * New option for conflict handling; allows stop (historical default), local, remote, both or merge. Uses an external merge binary (but can be configured, like diff). * New resolve action, to mark conflicts as resolved. * update can now be restricted to an arbitrary subset of URLs. Please note that that doesn't mean *partly* updating your working copy - it just means that if you use 50 URLs you can update a single one. Other small changes: - Filter option text now means removed entries, too. - urls dump can now work verbose to produce more human-readable output. - Checkout now prints the entries as they're checked out. - opt_parse() is now only optionally silent; the user gets better messages on wrong options. - I've tried to get better compatibility with Solaris. Tell me if your system isn't supported, or you get errors on ./configure or make. Bugfixes: - The option filter wasn't taken from config files. - Bugfix for st -N -N printing all deleted entries. - Fix for svn log | head -1 sometimes erroring out (EPIPE). status still has a problem. I'm working on a clean solution for _all_ commands, but have to think about a few corner cases first. - Querying the URL of entries could cause a buffer end (and so the heap, too) to be overwritten. - revert would save the dir-list, even when an error occurs. - Other small fixes and cleanups. Please fetch the sources from http://freshmeat.net/projects/fsvs as usual, or hope for your distribution packager to provide a package. If you have any feedback - be it positive or negative - please don't hesitate to provide it! There're two mailing lists (users and dev), or you can mail me directly. I'd be glad to hear about your experiences! 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]
[ANNOUNCE] FSVS 1.1.13 released
Hello everybody, FSVS 1.1.13 is released. This is a maintenance/quality release; it has a big amount of bugfixes, and I got the automated test coverage up to 92.9 percent! (If you count the error-handling lines, which just abort the program on errors like ENOSPC and similar, too, you get 95.5%). If you'd like to see the whole list of changes, please look in the changelog here: http://fsvs.tigris.org/source/browse/fsvs/tags/fsvs-1.1.13/fsvs/CHANGES?view=markup And for the other people - here's the short list of new features. * revert now reverts add/unversion/copy commands. * diff of copied entries now diffs against the copyfrom source. * New option to avoid the expensive MD5 copyfrom matcher. * New option to avoid empty commits. * FSVS_WARNING can now parse multiple warning options; but FSVS_WARNINGS is now deprecated. * New option delay - delays until a second wrap, used for scripts. Can be yes, no, or any combination of (some) action names. * Support for absolute ignore patterns; they ease expanding the wc area later. Warning if they don't match the wc base. Documentation can be found at http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/index.html; and an overview for users is http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__userdoc.html. Furthermore the source distribution now includes an example script that can be used to setup versioning of /etc; some configuration files for debian are included, to get a commit after each apt-get call. BUT READ THE README, AND MIND THE WARNING! You can get FSVS as usual from http://freshmeat.net/projects/fsvs, or you ask your distribution for an updated package. Please send your questions, ideas, and other feedback to the mailing lists; I'd be glad to hear from your experiences. If you write a blog, and have some tips or tricks to share, I'd be happy to put a link in the documentation section. 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]
[ANNOUNCE] FSVS 1.1.12 released
Hello everybody! Thinking about bigger changes, like copyfrom handling, doesn't really work in 30 minute pieces in the train; that's why this release took a fair bit longer than I'd wanted it to. Well, nevertheless, it got finished ... here are the results. Apart from the usual small bugfixes, cleanups, documentation and compatibility updates, the bigger changes are: - Fixed fsvs ignore dump to work in subdirectories; but now fsvs urls *must* be used for initialization. - A workaround for doxygen's misfeature of *always* interpreting /* and */ is implemented; so the ignore pattern documentation is now clearer. - People using fsvs on http and https URLs now get the properties filtered; they couldn't commit because a special property was handed to FSVS, that must not be sent to the repository. - The extended tests may now be run in parallel; that helps me a fair bit for QA. And, of course, there's a thing this release is mainly concerned with: - Copyfrom handling. Using fsvs cp should now work; for files and directories, for partial and full commits, ... - Furthermore the user can ask for a bit of information; verbose fsvs info prints copyfrom source, and a (basic) copyfrom-detection is implemented. /- I'd like ask for volunteers ... -\ | fsvs copyfrom-detect gives output, but some graphical way | | to see/use this information would be nice.| \- Perl/Tk, anyone? Or some dialog system? -/ Also the licence got changed to GPLv3; but this shouldn't make any difference to users :-) Please get the files from http://freshmeat.net/projects/fsvs/, as usual; people on debian can hope for an update package. Hints, tips and tricks, suggestions and ideas welcome! 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]
Binary size on ia64?
Hello developers! Looking at http://packages.debian.org/sid/fsvs I see that the binary size of fsvs is 276 kB on amd64 ... but 504 kB on ia64! Is that just the bigger instruction lengths, or what else? Can somebody explain me the difference? (Yes, I looked at http://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64 - but I haven't found something related) 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]
Re: fsvs ignore dump should work everywhere
Hello Alexander! ... It would be better, IMO, if this would also dump the ignore list. You're welcome - it's fixed in current trunk. 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]
Re: apr files not picked up?
In the truss trace I see this: 28535: 0.3057 execve(/u04/opt/csw/gcc4/bin/../libexec/gcc/sparc-sun-solaris2.8/4.0.2/cc1, 0x00042370, 0x000454B8) argc = 8 28535: argv: 28535: /u04/opt/csw/gcc4/bin/../libexec/gcc/sparc-sun-solaris2.8/4.0.2/cc1 28535:-E -quiet -iprefix 28535:/u04/opt/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.2/ 28535:-MM warnings.c -mcpu=v7 28535: envp: COLLECT_GCC_OPTIONS='-MM' '-mcpu=v7' 28535:GCC_EXEC_PREFIX=/u04/opt/csw/gcc4/bin/../lib/gcc/ 28535:COLLECT_GCC=/opt/csw/gcc4/bin/gcc CC=/opt/csw/gcc4/bin/gcc 28535:CPP=/opt/csw/gcc4/bin/cpp 28535:CPPFLAGS=-I/opt/csw/include -I/opt/csw/apache2/include -I/opt/csw/include/subversion-1 So a C compiler is called, and it gets the -I options. But later it tries to find apr_md5, and fails: 28535: 0.3685 open(/u04/opt/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.2/include/apr_md5.h, O_RDONLY|O_NOCTTY) Err#2 ENOENT 28535: 0.3686 open(/opt/csw/include/apr_md5.h, O_RDONLY|O_NOCTTY) Err#2 ENOENT 28535: 0.3687 open(/opt/csw/gcc4/include/apr_md5.h, O_RDONLY|O_NOCTTY) Err#2 ENOENT 28535: 0.3687 open(/usr/include/apr_md5.h, O_RDONLY|O_NOCTTY) Err#2 ENOENT And this happens if you use CFLAGS, too. The Makefile has %.o: %.c @echo CC $ @$(CC) $(CFLAGS) -c -o $@ $ so the CFLAGS should be given as parameters, not as environment ... why doesn't that work? Please stick an echo in front of the CC, and send me the output: @echo $(CC) $(CFLAGS) -c -o $@ $ Can I take a look at the situation? Is there some (reasonably small) image for qemu you can send me? 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]
Re: apr files not picked up?
On Saturday 08 December 2007 Alexander Skwar wrote: ... They are the results of running: CC=/opt/csw/gcc4/bin/gcc CPP=/opt/csw/gcc4/bin/cpp \ LDFLAGS=-L/opt/csw/lib -L/opt/csw/apache2/lib -L/opt/csw/lib/svn \ CPPFLAGS=-I/opt/csw/include -I/opt/csw/apache2/include -I/opt/csw/include/subversion-1 \ PATH=/opt/csw/gcc4/bin:/opt/csw/gnu:/opt/csw/bin:$PATH \ /usr/bin/truss -o ../compile-fsvs-truss.txt -ade \ /opt/csw/gnu/make ... Could you try using CFLAGS instead of CPPFLAGS? 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]
Re: environ undeclared in helper
On Friday 07 December 2007 Alexander Skwar wrote:
Philipp Marek schrieb:
On Friday 07 December 2007 Alexander Skwar wrote:
helper.c: In function 'hlp__match_path_envs':
helper.c:1423: error: 'environ' undeclared (first use in this function)
helper.c:1423: error: (Each undeclared identifier is reported only once
helper.c:1423: error: for each function it appears in.)
helper.c: In function 'hlp__format_path':
helper.c:1580: error: 'environ' undeclared (first use in this function)
Is there some header file that declares environ?
Doesn't look like. Attached, you can find the output
of
grep -r environ /usr/include
Thank you ... environ is in SUS ... don't know why that doesn't work.
I'd like to take a look at that ... maybe there is some function to get that
pointers.
How about that?
Index: fsvs.c
===
--- fsvs.c (Revision 1255)
+++ fsvs.c (Arbeitskopie)
@@ -310,6 +310,9 @@ apr_pool_t *global_pool;
struct url_t *current_url;
+/** For Solaris, which doesn't have one ... */
+char **environ=NULL;
+
/** -.
* Never called directly, used only via the macro DEBUGP(). */
@@ -769,7 +772,7 @@ void *_do_component_tests(int a)
* in a clean list.
* - And calls the main action.
* */
-int main(int argc, char *args[], char *environ[])
+int main(int argc, char *args[], char *env[])
{
struct estat root = { };
int status, help;
@@ -781,6 +784,7 @@ int main(int argc, char *args[])
help=0;
eo_args=1;
+ environ=env;
program_name=args[0];
#ifdef ENABLE_DEBUG
/* If STDOUT and STDIN are on a terminal, we could possibly be
Index: global.h
===
--- global.h(Revision 1254)
+++ global.h(Arbeitskopie)
@@ -845,4 +845,7 @@ extern int start_path_len;
#define ANSI__NORMAL \x1b[0;0m
/** @} */
+/** For Solaris */
+extern char **environ;
+
#endif
--
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]
Re: apr files not picked up?
On Friday 07 December 2007 Alexander Skwar wrote: Hello again :) I'm trying to get fsvs to compile on a Solaris 10 Sparc system. To configure, I ran: CC=/opt/csw/gcc4/bin/gcc CPP=/opt/csw/gcc4/bin/cpp \ LDFLAGS=-L/opt/csw/lib -L/opt/csw/apache2/lib -L/opt/csw/lib/svn \ CPPFLAGS=-I/opt/csw/include -I/opt/csw/apache2/include -I/opt/csw/include/subversion-1 \ PATH=/opt/csw/gcc4/bin:/opt/csw/gnu:/opt/csw/bin:$PATH \ ./configure \ --prefix=$HOME/.software --with-aprinc=/opt/csw/apache2/include \ --with-aprlib=/opt/csw/apache2/lib --with-svnlib=/opt/csw/lib/svn \ --with-svninc=/opt/csw/include/subversion-1 Now I'm trying to make it: CC=/opt/csw/gcc4/bin/gcc CPP=/opt/csw/gcc4/bin/cpp \ LDFLAGS=-L/opt/csw/lib -L/opt/csw/apache2/lib -L/opt/csw/lib/svn \ CPPFLAGS=-I/opt/csw/include -I/opt/csw/apache2/include -I/opt/csw/include/subversion-1 \ PATH=/opt/csw/gcc4/bin:/opt/csw/gnu:/opt/csw/bin:$PATH \ /opt/csw/bin/gmake The Makefile overrides these; but they should have been picked up by the configure. Could you send me the output of diff -u src/Makefile.in src/Makefile please? -- 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]
Re: apr files not picked up?
On Friday 07 December 2007 Alexander Skwar wrote: ... They have. Without LDFLAGS/CPPFLAGS and/or --with-..., configure fails, as the header files cannot be found. Could you send me the output of diff -u src/Makefile.in src/Makefile please? Sure. It's attached. You're using gcc, and it gets CFLAGS:= ... -idirafter /opt/csw/apache2/include Why doesn't it find the files? What happens if you change all -idirafter to -I? -- 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]
Re: environ undeclared in helper
On Friday 07 December 2007 Alexander Skwar wrote: helper.c: In function 'hlp__match_path_envs': helper.c:1423: error: 'environ' undeclared (first use in this function) helper.c:1423: error: (Each undeclared identifier is reported only once helper.c:1423: error: for each function it appears in.) helper.c: In function 'hlp__format_path': helper.c:1580: error: 'environ' undeclared (first use in this function) Is there some header file that declares environ? -- 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]
Re: stray '#' in program and environ undeclared
On Friday 07 December 2007 Alexander Skwar wrote:
Now I'm getting this compile error:
CC export.c
CC fsvs.c
fsvs.c: In function 'Version':
fsvs.c:539: error: stray '#' in program
r1255.
fsvs.c:539: error: called object 'compile options:\012\011 HAVE_LOCALES=1
AC_CV_C_UINT32_T=uint32_t HAVE_STRUCT_STAT_ST_MTIM=1 O_DIRECTORY==(0)=' is
not a function fsvs.c:544: error: syntax error before string constant
fsvs.c: In function 'main':
fsvs.c:852: error: 'environ' undeclared (first use in this function)
fsvs.c:852: error: (Each undeclared identifier is reported only once
fsvs.c:852: error: for each function it appears in.)
gmake[1]: *** [fsvs.o] Error 1
gmake: *** [default-target] Error 2
environ is SUS:
environ - array of character pointers to the environment strings
http://opengroup.org/onlinepubs/007908799/xsh/environ.html
Does that help?
diff fsvs.c
Index: fsvs.c
===
--- fsvs.c (Revision 1255)
+++ fsvs.c (Arbeitskopie)
@@ -769,7 +769,7 @@ void *_do_component_tests(int a)
* in a clean list.
* - And calls the main action.
* */
-int main(int argc, char *args[])
+int main(int argc, char *args[], char *environ[])
{
struct estat root = { };
int status, help;
--
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]
Re: FSVS on gentoo crashes
On Tuesday 13 November 2007 Alexander Skwar wrote: Hello Phil! On Nov 9, 2007 6:04 PM, Philipp Marek [EMAIL PROTECTED] wrote: On Friday 09 November 2007 Philipp Marek wrote: ... It seems that you have at least to patch configure.in, so that libc6=2.7 gets accepted - I'd suggest just changing the 2.6 to 2.7, that could work. ... That patch worked just fine. Now, what do I do with valgrind? :) On Friday 09 November 2007 Philipp Marek wrote: and try this: valgrind --leak-check=full --show-reachable=yes --num-callers=15 --log-file=/tmp/valgrind.out --time-stamp=yes ~...fsvs st Please send me the logfile (can be privately, if you prefer). ;-) -- 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]
FSVS on gentoo crashes
Hello everybody, in issue 1 (http://fsvs.tigris.org/issues/show_bug.cgi?id=1) I got a problem report that fsvs crashes on a current gentoo box. I had a look last night (remote logging in), but could not find a bug in fsvs (although I cannot say there is none, of course :-). My current ideas regarding the problem source are: - gentoo kernel (tested 2.6.22, 2.6.23), using NFS - libc6 v2.7 The problem is that realloc() aborts with the message that the heap is corrupted; valgrind doesn't yet run on libc6=2.7, else we'd have testet. Now I'd like to ask gentoo users: - which kernel, libc6 are you running? - is it stable (I'd assume yes, else I'd have heard) - are you by chance using NFS? If there are any other users running 2.6.22 or 2.6.23, or using libc6=2.7, or having NFS directories versioned, I'd like to hear from them, too. Maybe we can eliminate some factors, to find the problem source. Please answer only to users@; I'd like to keep the dev@ thread centered on technical detail. Thank you! 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]
Re: FSVS on gentoo crashes
Here's the thread about technical information. The problem seems to be - running dir__enumerator - on a directory with a stat() size of 414 bytes, - but having ~21k of filenames (414 is # of entries including . ..), the initial size allocation is too low, so that in the loop all the arrays have to be resized several times - and then realloc() tells about the corrupted heap (on the 3rd or 4th reallocation of names). Strangely, a watchpoint in GDB gave realloc() as worst offender (changing the few bytes before *names); using MALLOC_CHECK_=2 and inserting mcheck() calls identified line 556, which is (in the modified sources) the line size=(size*19)/16+1 (or similar) as offender, which is clearly bogus ... unless the C compiler (gcc 4.2.2, IIRC) is bad. I've had a look at alloc_count and count, too; but once, while alloc_count==200 and count==174, the heap was reported corrupted after the names[count]=... line - while there should enough space be there, so I can't explain that. valgrind doesn't yet run on libc6=2.7. Changing the initial allocation to some big value makes FSVS run. 2.6.22 had some reported NFS issues ... but they'd have to scribble over user-space memory. Any other ideas? -- 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]
Re: FSVS on gentoo crashes
Hello Alexander, would you please check out the current valgrind sources svn co svn://svn.valgrind.org/valgrind/trunk valgrind cd valgrind ./autogen.sh ./configure --prefix=... make make install (from http://valgrind.org/downloads/repository.html) and try this: valgrind --leak-check=full --show-reachable=yes --num-callers=15 --log-file=/tmp/valgrind.out --time-stamp=yes ~...fsvs st Please send me the logfile (can be privately, if you prefer). Thank you! 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]
Re: FSVS on gentoo crashes
On Friday 09 November 2007 Philipp Marek wrote:
... It seems that you have at least to patch configure.in, so that
libc6=2.7 gets accepted - I'd suggest just changing the 2.6 to 2.7, that
could work.
About this: (untested)
diff -u configure.in.orig configure.in
--- configure.in.orig 2007-11-09 17:38:56.0 +0100
+++ configure.in2007-11-09 18:03:45.0 +0100
@@ -467,6 +467,8 @@
],
libc=aix5)
+libc=2.6
+
AC_MSG_CHECKING([the libc version])
case ${libc} in
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]
Re: FSVS on gentoo crashes
Hello Alexander! On Friday 09 November 2007 Alexander Skwar wrote: I'll try this on Monday; right now I don't have access to the system. Thank you. It seems that you have at least to patch configure.in, so that libc6=2.7 gets accepted - I'd suggest just changing the 2.6 to 2.7, that could work. 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]
Re: FSVS debs
Hello Mark, On Tuesday 23 October 2007 Petersen, Mark wrote: Have you made any progress in creating a debian package for fsvs? I know it's not on pdo yet. I'll cc dev@ and Sheldon for your question: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428311 Last thing I know that Sheldon was looking for some sane man-page format, and possibly some initial configuration defaults. This is just the project I was looking for to store configs for various things in. Maybe whole systems down the road. Fine, that's what it's for. 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]
Re: Commit Error - Failed to execute WebDAV PROPPATCH
Hello Bjorn!
On Wednesday 17 October 2007 Bjorn Oglefjorn wrote:
With the latest patches Phil and I worked out yesteday, I'm getting the
following error when I attempt to commit a change to the repository:
...
Does that work?
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
Index: update.c
===
--- update.c (Revision 1176)
+++ update.c (Arbeitskopie)
@@ -138,6 +138,7 @@
apr_time_t at;
svn_error_t *status_svn;
const char prop_pre_toignore[]=svn:entry;
+ const char prop_pre_toignore2[]=svn:wc:;
/* We get the name and value in UTF8.
@@ -314,7 +315,12 @@
* store them?? */
/* ignore svn:entry:* properties */
/* check for is_import_export */
- if (strncmp(utf8_name, prop_pre_toignore, strlen(prop_pre_toignore)) != 0)
+ if (strncmp(utf8_name, prop_pre_toignore, strlen(prop_pre_toignore)) == 0 ||
+strncmp(utf8_name, prop_pre_toignore2, strlen(prop_pre_toignore2)) == 0)
+ {
+ DEBUGP(ignored property %s=%s, loc_name, loc_value);
+ }
+ else
{
sts-remote_status |= FS_PROPERTIES;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Auth via http(s)?
On Tuesday 16 October 2007 Bjorn Oglefjorn wrote: This was very difficult to capture since it filled my screen buffer so quickly, but I've finally got it. Ignore the gaps in the time stamps as I had to cut and paste this together from a few different runs. A tip: use something like fsvs -d . | tail -1000 /tmp/logfile The debug messages go to STDOUT - so that they're easy to capture. That might be easier :-) From a quick glance it seems that https:// gives no close(), ie. svn_stream_close() doesn't get called. I'll have a look. Thank you! 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]
Re: Auth via http(s)?
Hello Bjorn, So, this is definitely a step in the right direction. Compiles, builds and installs fine. Authorization works also, however after the auth there are some new problems. This is a snippet from lsof showing what the fsvs process is doing: fsvs 4732 root3u REG 253,0 6211 721999 /etc/cobbler/centos4-server.ks.OYfWdk fsvs 4732 root4u IPv4 9842 TCP somehost.mydomain:32811-svn.mydomain:https (CLOSE_WAIT) fsvs 4732 root5w REG 253,0 1008342464 327893 /var/spool/fsvs/97/69/e018cb632af76862fbc6e2ba3d82/md5s.tmp The CLOSE_WAIT is likely an issue... strace shows the following being written to the FD 5: write(5, ..., 64) = 64 which you can see is the file shown above in lsof: [EMAIL PROTECTED] /proc/4732/fd]# ll total 6.0K dr-x-- 2 root root 0 Oct 15 11:23 ./ dr-xr-xr-x 3 root root 0 Oct 15 11:22 ../ lrwx-- 1 root root 64 Oct 15 11:23 0 - /dev/pts/0 lrwx-- 1 root root 64 Oct 15 11:23 1 - /dev/pts/0 lrwx-- 1 root root 64 Oct 15 11:23 2 - /dev/pts/0 lrwx-- 1 root root 64 Oct 15 11:23 3 - /etc/cobbler/centos4- server.ks.OYfWdk lrwx-- 1 root root 64 Oct 15 11:23 4 - socket:[9842] l-wx-- 1 root root 64 Oct 15 11:23 5 - /var/spool/fsvs/97/69/e018cb632af76862fbc6e2ba3d82/md5s.tmp* fsvs is continually writing 6211 0 to that file with no end in sight. Is there any more debug info I can provide for you? Always the same string? The third field is the file position, and the 4th the length ... Should not be possible to do 0 bytes - there's a minimum length of 2048 or some such defined. Could you send me the last (20, 50 or so) meaningful lines of the same command with -d? There's likely to be some repetition, and one instance of that plus some lines from above would be nice. 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]
[ANNOUNCE] FSVS 1.1.10 released
Hello everybody,
I'm sorry to announce 1.1.10.
Why? Because copy/move detection/marking has *still* not made it.
I'm working on that; but it's a fair bit of design, and not fully
finished yet. Please hold on; I won't forget.
However, due to the amount of changes lately, I decided to releasea a new
version; the changes since 1.1.9 are:
Multi-URL operations:
* Bugfix for detection of duplicate URL names.
* Bugfix for master/local operation, when dir from URL1 gets a new entry,
which should be committed in URL2 -- so the directory has to be created
in URL2.
* Bugfix for multi-URL-operation with separated repositories -
use the correct revision numbers. There's now a HOWTO for multi-repos
operation, see
http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__howto__master__local.html
Performance updates:
* Bugfix for directories in $FSVS_WAA - create only needed ones.
If you look into your $FSVS_WAA, you'll notice a *big* amount of empty
directories ... which are no longer generated with this version. I'd even
recommend cleaning up via 3 runs of cd $FSVS_WAA find . -type d -exec
rmdir {} \; find . -type d -exec rmdir {} \; That'll give a lot of errors
for non-empty directories, but should otherwise work fine. This change
also means that the (local) property storage changed to UTF8, where the
names previously were stored in local encoding! Currently
non-ASCII-properties are broken.
* A Memory leak in revert for many files fixed; for big files there's a
leak in the subversion binaries, see
http://marc.info/?l=subversion-devm=119163134522300w=2
* Performance fix for cs__compare_file() (st -C, update, commit) -
it didn't recover into a zero-block after a few non-zero characters.
* Removed the usleep() in the encoder loops (fsvs:update-pipe,
fsvs:commit-pipe).
For a 10MB file, encoder=cat: old time 7.1sec, new 0.33sec; using dd
bs=1024k gets it down to 0.3sec (cat uses only a 1024 bytes buffer).
User interface:
* Using -q caused *more* output on errors.
* Error messages for invalid URL input now user-friendlier.
* Properties may no longer be set on unknown entries.
* Property changes showed in status as - now they get displayed in
the meta-data column(s).
* Status output changed; in certain cases (much too often) a n instead of
N would be printed. Now corrected.
* Output beautification for sync-repos - use or the wc-path given on the
command line, don't simply print the full path.
Others:
* Various small fixes and cleanups.
* Changed the internal ignore -- from $FSVS_WAA to $FSVS_WAA/*.
That allows to have $FSVS_WAA versioned (as it's needed), but reliably
ignore entries below. (Still via inode numbers, so still fast.)
* Bugfix for -f text - if a directory structure was removed, the child
wouldn't see the parent removed, which results in a chdir()=ENOENT.
Of course, there's a new feature, too :-)
* Support for log -v, to show filenames.
If you use FSVS in scripts, please be aware of the status output change;
an additional character for property changes for verbose output, and a
low-priority sharing of the 'm' position; see
http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/group__cmds.html#status
Please get the files from http://freshmeat.net/projects/fsvs/, as usual;
a bit of documentation is included in the tarball, the full one can be
generated via doxygen and is also available online:
http://fsvs.tigris.org/source/browse/*checkout*/fsvs/trunk/www/doxygen/html/index.html
Hints, tips and tricks, suggestions and ideas welcome!
Please do not hesitate to ask, if you've got any problems.
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
--
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]
Re: Recursive Revert
On Friday 28 September 2007 Simon Sprünker wrote: I am using svn+ssh://. With svn+ssh:// and a 100MB random-bytes file I can reproduce the memory usage. The only problem is ... it doesn't seem to be a problem in my functions, but in subversion: Breakpoint 1, 0x2b4c96ff7540 in sbrk () from /lib/libc.so.6 (gdb) bt #0 0x2b4c96ff7540 in sbrk () from /lib/libc.so.6 #1 0x2b4c96fa1649 in __default_morecore () from /lib/libc.so.6 #2 0x2b4c96f9d997 in ?? () from /lib/libc.so.6 #3 0x2b4c96f9ed63 in malloc () from /lib/libc.so.6 #4 0x2b4c973b84dc in apr_palloc () from /usr/lib/libapr-1.so.0 #5 0x2b4c965bcea6 in svn_stringbuf_ensure () from /usr/lib/libsvn_subr-1.so.1 #6 0x2b4c965bcf32 in svn_stringbuf_appendbytes () from /usr/lib/libsvn_subr-1.so.1 #7 0x2b4c9844758f in ?? () from /usr/lib/libsvn_ra_svn-1.so.1 #8 0x2b4c9844764d in svn_ra_svn_read_item () from /usr/lib/libsvn_ra_svn-1.so.1 #9 0x2b4c98440acc in ?? () from /usr/lib/libsvn_ra_svn-1.so.1 #10 0x00413a91 in rev__get_file (sts=0x63baf0, revision=10, fetched=0x7fff147299d8, only_tmp=0x0, pool=value optimi #11 0x00414505 in rev__action (sts=0x63baf0, path=0x63d178 ./asdf) at revert.c:445 #12 0x00404024 in ac__dispatch (sts=0x63baf0, path=0x63d178 ./asdf) at actions.c:53 #13 0x0041a762 in waa__update_tree (root=value optimized out, cur_block=0x63bbe0) at waa.c:1894 #14 0x0041a97b in waa__partial_update (root=0x7fff14729b80, argc=1, normalized=0xf000, orig=0x7fff14729d #15 0x0041c84c in waa__read_or_build_tree (root=0x7fff14729b80, argc=1, normalized=0x632350, orig=0x7fff14729d88, re #16 0x00413546 in rev__work (root=0x7fff14729b80, argc=1, argv=0x7fff14729d88) at revert.c:556 #17 0x0040c78c in main (argc=4, args=0x7fff14729d78) at fsvs.c:991 The memory gets allocated to increase a stringbuf ... although revert.c:176 says stream=svn_stream_from_aprfile(a_stream, subpool); so it should go directly into a file. (BTW, the same happens on update - and I can reproduce it there, too.) I've got libsvn1=1.4.4dfsg1-1. So, for a summary -- I can see the problem, but as yet I don't know where it happens. 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]
Re: Recursive Revert
Hello Simon! the report didn't find anything regarding fsvs, then some things distracted me from looking further into it. I did however test version 1.1.9 in my virtual machine. A complete revert of / still used too much memory and got killed by the system. Initially the VM had 300 MB, then I increased to 800 MB, but the problem persisted. Here is what happens in the file system: When the revert starts, it processes some man-pages, then /var/lib, then three linux sources (which take really long), and I think then a quite big file is read from the repository. During this operation the fsvs process gets killed, but when the big file is starting to be processed, fsvs uses already about 80% of system memory. Does this help you? Well, I'll try to reproduce this problem. Which versions of libapr and libsvn are you using? 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]
Re: fsvs-rev1088 sync-repos (debug log)
On Tuesday 28 August 2007 Benjamin M. wrote: Talking of sync-repos, I just noticed... I'm getting a duplicate line at the end... # fsvs sync-repos ... N... dir /etc/modprobe.d N... 0 /etc/modprobe.conf N... dir /etc ..C. dir / ..C. dir / duplicate sync-repos for file:///root/fsvs/asterisk-01/repository/trunk rev 2. Yes, I saw that too. Will be done in the next time. But I think you should really prioritize the fsvs add creating empty files bug... since it can leads to data loss... Hmmm ... was the file versioned before the add? 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]
Re: FSVS: ./configure failed since 1.1.7 (CentOS 5)
On Monday 27 August 2007 Benjamin M. wrote: ... When subversion is built with --with-ssl, fsvs ./configure returns lot of errors in config.log if -lssl isn't included, that is why it returns Sorry, can't find subversion. I obviously do not have an answer to your question but by looking for support for one of the ssl functions listed there, you should be able to detect support for ssl... I guess..: Maybe ... I'll take a look. The SEGV could be fixed in current trunk. Yep. Works flawless (rev1088) ... But I have an other SEGV on sync-repos I will send you the debug log in private. Got it, thank you. Otherwise here a weird behavior with diff: ... I would expect to get diffs on modified files... not the complete list of /etc and some hidden files at the root level... That's strange. Do you have a fsvs st -d? But that might be big ... Did you ignore everything but /etc? Or is /etc your working copy? ... # fsvs diff Only in local filesystem: ./.asterisk_history Only in local filesystem: ./.autofsck Only in local filesystem: ./.autorelabel Strange. 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]
Re: FSVS: ./configure failed since 1.1.7 (CentOS 5)
On Saturday 25 August 2007 Benjamin M. wrote: No problem with 1.1.6 but since 1.1.7 I get the following error on ./configure. Any idea? # ./configure --prefix=/usr/local/fsvs-1.1.8 configure: *** Now configuring FSVS *** checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E ./configure: line 2904: apr-config: command not found - ?? configure.in has AC_ARG_WITH(aprinc, AC_HELP_STRING([--with-aprinc=PATH], [Specify an include directory for the APR headers.]), [ INCDIRS=$INCDIRS $withval ], [ if APR=`apr-config --includedir` then INCDIRS=$INCDIRS $APR fi ]) which should take a --with-aprinc=path parameter, or, if none set, should run the program apr-config and try to get the path from there. You didn't give a path, and apr-config could not be found. Where apr-config is supposed to come from? # locate apr-config /usr/src/apr-1.2.9/apr-config.in /usr/src/apr-1.2.9/apr-config.out CentOS 5.0 apr-1.2.9 apr-iconv-1.2.0 apr-util-1.2.8 I have $ dpkg-query -S apr-config libapr1-dev: /usr/share/man/man1/apr-config.1.gz libapr1-dev: /usr/bin/apr-config so you might be missing a development package. configure: CFLAGS=-g -O2 -D_GNU_SOURCE=1 -D_FILE_OFFSET_BITS=64 -idirafter /usr/local/include -idirafter /usr/include -idirafter /openpkg/include configure: LDFLAGS= -L/usr/local/lib -L/openpkg/lib checking for pcre_compile in -lpcre... yes checking for apr_md5_init in -laprutil-1... yes checking for svn_ra_initialize in -lsvn_ra-1... no - ?? configure: error: Sorry, can't find subversion. See `config.log' for more details. autoconf-2.61 subversion-1.4.4 (with-ssl) Same here, I think: $ dpkg-query -S apr-config libapr1-dev: /usr/share/man/man1/apr-config.1.gz libapr1-dev: /usr/bin/apr-config On the frontpage http://fsvs.tigris.org/ is written: For CentOS5 (and probably RHEL5) I got this line from a user: yum install subversion subversion-devel ctags apr apr-devel gcc gdbm gdbm-devel pcre pcre-devel Sorry, but did you read the documentation ;-? Hope it's only that. 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]
Re: Detecting copies/moved files
Hello Gunter! On Sunday 26 August 2007 Gunter Ohrner wrote: Just a few questions to make sure I understood your ideas correctly, and one or another thoughts of mine... Am Sonntag, 26. August 2007 schrieb Philipp Marek: - There'll be fsvs copy/fsvs move commands, which (when given some parameter) will call cp -a/mv with the arguments, for manual copy/move. This will copy / move the file and additionally track this change for later submission to the repository server? Right. - Likewise some fsvs copied-from, to tell what already *has* been done. Is this meant to tag historical data which was already copied / moved and comitted some time ago, before fsvs was ready to track this? No, that was meant to be in case some other process did this, and you'd like to tell FSVS that it should use this information - just like above, but without the actual copy/rename. Or is it merely for tracking copy / move-operations performed using standard command line or graphical tools before comitting the changes? Yes. - On commit itself normally no such things would happen; although there'll probably be some option to re-enable that. Question: Would there be any drawbacks of automagic copy / move detection? I currently do not see why detect-copies should not be performed (and the resulting information used) on any commit. False positives and negatives? distinct rename operation, there's a problem: If file A is missing, but there are B and C with the same data -- is one renamed, and the other copied? My first though was: Both are copies and the original is deleted afterwards. Yes, that's what I tried to say in the indented paragraph. - What about small files, which share the same MD5 because they have the same data, but are different in the meaning of independent? (Eg. the default config data in users' home directories). Mh, what's about these? As long as these files are identical, it's fine, and as soon as one copy changes it will deviate from the other copies, just as it happens on the local disc. At least that's the way it's done in a standard subversion working copy - will fsvs handle it differently? The problem I see is that with normal subversion copy semantics some kind of relationship between /home/a/.kde/XXX and /home/b/.kde/XXX would be drawn. Of course, if you have /etc/skel/ versioned too, then that could be used as source of the various /home/*/ directories ... and all would be fine. I mostly fear confusion in a way of ~a/.bashrc is copied from ~b/.bashrc, and ~a/.kde is copied from ~c/.kde ... which would not be good. - For big files that share some data, we can use the pre-existing manber-hashes ... that's what they are there for. How do you want to share common parts within big files? Is the subversion repository able to handle something like that? Is it useful at all? No, I don't think such things can (currently) be shared. The only use for such things is I rename my MP3 file, and change that ID tag ... then they wouldn't be identical, but have a common history. If the large files have a single source and still are similar but also already have been comitted, it's too late as the storage space within the repository is occupied twice already. That's right. All copy-from information must be known before commit. If a file is duplicated using a copy and FSVS uses the copy-from information, and both copies deviate, a future fsvs will track this and the subversion repository will only record the changes using its xdelta algorithm anyway. How would tracking those be needed? Of course, FSVS should happily use the delta information (where applicable instead of full-text) -- but tracking? Of course, subversion will just record changes. Another case - B is copied from A, and committed with this information. Later A is changed (A'), and B copied again (B') ... should now B' have history to B, or to A'? So, to be honest, I see no point in doing anything special to big files - probably I've not yet understood what you actually want to achieve by this... ;) Maybe you could elaborate? Big files are only a single way special - FSVS already computes the manber-hashes (although very coarse ones), to speed up checking for changes. - Could we use the inode number for detecting moved files? Only on No, an fsvs managed directory tree may reside on multiple local filesystems, or isn't that supported? (I think I didn't try it yet, but it would certainly be the case for me if I managed my whole system installation using fsvs - /, /usr, /var all are on different disks or at least disk partitions.) Yes, but if you do mv /usr/bin/a /usr/bin/c they'll have the same inode number. MD5 is more robust against stuff like this. Yes, but much more computing intensive. However, using the inodes would help - no, would be required - to allow hardlink tracking, so once hardlink support is added to fsvs, MD5 sums might be used as well as the inode
Re: FSVS: ./configure failed since 1.1.7 (CentOS 5)
On Sunday 26 August 2007 Benjamin M. wrote: Philipp Marek wrote, On 26/08/07 04:33: You didn't give a path, and apr-config could not be found. I just realized that I have apr-1-config but not apr-config... creating a symbolic link: ln -s apr-1-config apr-config seems to fix the error... I'll try to use that, if it exists, too. subversion-1.4.4 (with-ssl) Adding LIBS=-lssl before ./configure fixes the error... perhaps it should be added in the configure file... H ... how could I detect that it's needed? I will try to torture fsvs tonigh... so your TODO list would not stay empty too long! ;-)) As if it ever was ... The SEGV could be fixed in current trunk. Regarding the failing test 003: Which rsync version do you use? 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]
fsvs cat ...
In case anyone's interested in implementing this ... I'd suggest splitting rev__get_file() in two - in a part that fetches the decoder (if needed) and writes the decoded output to a svn_stream_t, and the rest just calling this part. Then it's just a small matter of making a new command cat, which uses this function in the worker function ... In case more than a single file is given it might make sense to offer several alternatives (via options): - just pipe, as is, concatenated - MIME-separated - in some kind of tar format? so that they can be piped to another location, and re-separated there again? Probably too much work. - Write them to files in another location? But that's export ... BTW, I think export doesn't take the decode filter yet ... If someone's interested, please reply with a short answer ... so that it isn't done twice. 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]
Re: Using fsvs as UID 0
On Friday 09 March 2007 17:42 Benjamin M. wrote: I would be thrilled to be able to give you an answer... Then why don't you? In the meantime I will only be able to give you problems to solve... ;-) About 015 ... no luck with r732... Yes, I know. I'm working on that ... should be done by Monday. 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]
Re: ignore globbing patterns are not anchored
On Friday 13 October 2006 21:15 Gunter Ohrner wrote: Am Mittwoch, 11. Oktober 2006 17:19 schrieb Philipp Marek: As the manual does not mention this at all and there is no privision to achor a globbing paattern explicitely, I think this is a bug. I know that this makes sense in a way - but using a pattern like ./directory/ ignores currently everything below this directory, which makes sense, too. How about a flag or allowing $ at the end? Allowing a $ at the end of the pattern would be ok, but not intuitive - usually globbing patterns in UNIX do not know about a $ but are anchored automatically. A flag in contrast would be fine, and/or unanchored behaviour if the strings ends with a / - that'd be also fine in my eyes, as it would not unexectedly match substrings in filenames and still allow easily ignoring whole subtrees in a natural way. There's also still the possibility to write ./dir/** although that looks awkward and isn't intuitive, either. I think I'd opt for anchoring iif the last character is no slash. Excluding directories but not their contents doesn't make sense anyway. And if one really wants to mach a substring of a filename, one can write ./**/*bla* or stuff like this. If more complex paatterns are desirec, PCREs are the way to go, anyway, but globbing patterns are more common and easier readable for the day-to-day filename matching tasks, IMHO. However, independant of the solution which will be implemented it's neccessary to be able to anchor the patterns (if that won't become the default behaviour) and to extend the IGNORING document with a sentence or two explaining the choosen behaviour. :-) I wholeheartly agree with you. Do you have a patch that does all this, maybe :-? -- 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]
Re: FSVS MacOS 10.4: run-tests
On Saturday 23 September 2006 18:23 Benjamin M. wrote: Attached the run-tests results... $ svn update At revision 444. That was a make run-tests VERBOSE=1? Or did you patch the Makefile to get verbose output? Did you restart the tests after the failures, or did they run through? Normally they should stop at the first error, and should not produce the verbose output. Did you change the path for the tests? I see /private/tmp in the log file. 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]
Re: fsvs openbsd MacOS 10.4
Hello Ben! On Tuesday 19 September 2006 08:35 Philipp Marek wrote: Why does the printf() fault? (Hiding in a corner, with very small voice) How about now? 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]
Re: fsvs openbsd MacOS 10.4
On Friday 15 September 2006 20:47 Benjamin M. wrote: Here the results. ... 14:00:38.464 ops__build_path[est_ops.c:593] status=0; path=./.svn/text-base/build.c.svn-base Bus error Do you have some debugger on this system? gdb, ddd, something else? Please try running fsvs with it's control, or have a look at fsvs.c:308 - there a debugger is started if configured with --enable-debug and on a segmentation violation. I'd like to see a backtrace, or at least the code line where it faults - with only debug outputs it a bit tiring to find the place where fsvs dies ... 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]
Re: fsvs openbsd MacOS 10.4
On Saturday 09 September 2006 21:43 Julien TOUCHE wrote: $ set | egrep ^LC_ nothing? $ echo $LANG nothing? $ locale bash: locale: command not found isn't here? What happens if you lie to fsvs and try a utf8-locale? $ locale -a | grep utf8 should show you some, and then $ LC_ALL=the locale you try make run-tests $ echo $LC_ALL $ LC_ALL= gmake run-tests ... An error occurred at 21:35:02.933: Invalid argument (22) in hlp___get_conv_handle: Conversion from 646 to UTF-8 is not supported ... $ LC_ALL=C gmake run-tests ... An error occurred at 21:35:31.906: Invalid argument (22) in hlp___get_conv_handle: Conversion from 646 to UTF-8 is not supported ... $ LC_ALL=en gmake run-tests ... An error occurred at 21:36:58.695: Invalid argument (22) in hlp___get_conv_handle: Conversion from 646 to UTF-8 is not supported ... $ LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 gmake run-tests ... An error occurred at 21:41:31.334: Invalid argument (22) in hlp___get_conv_handle: Conversion from 646 to UTF-8 is not supported ... also fsvs -d st returned: 19:14:46.172 main[fsvs.c:443] LC_ALL gives C 19:14:46.174 main[fsvs.c:450] LC_CTYPE gives C 19:14:46.174 main[fsvs.c:461] codeset found to be 646 I now found two posts http://gcc.gnu.org/ml/java-patches/2002-q1/msg00944.html and http://archives.postgresql.org/pgsql-hackers/2003-05/msg00744.php; according to them you could try with LC_CTYPE=8859_1 or LC_CTYPE=ASCII. maybe if somes functions you use are dependent on configure/compile options of libiconv ? I don't know, I thought that these were standard UNIX functions with some default behaviour? 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]
Re: fsvs rev413: errors on run-tests 015 / 016 (linux)
On Sunday 03 September 2006 22:53 Benjamin M. wrote: Attached the results of run-tests 015/016 on my Linux box... the other tests run smoothly... The directory where nodes are being created isn't seen as changed. What filesystem run the tests on? Could you send me the output with the attached patch? Thank you! Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)! === test/016_add_unversion == --- test/016_add_unversion (revision 477) +++ test/016_add_unversion (local) @@ -20,7 +20,8 @@ $BINq ignore ./* # Maybe we get a ., possibly a m ... # Depends on timing of directory/inode changes (eg. same/different second) -if [[ `$BINdflt st` == .?C? * *. ]] +$BINdflt st -d -v +if [[ `$BINdflt st | egrep -v ' .$'` == ]] then echo OK, all ignored else - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fsvs openbsd MacOS 10.4
On Friday 01 September 2006 19:17 Julien TOUCHE wrote: what's that ... lot of things !!! What really makes me wonder is that: ... 19:14:46.185 dir__enumerator[direnum.c:367] found 82944 (null) ... 19:14:46.187 hlp__lstat[helper.c:232] .warnings.d: uid=1000 gid=0... ... N... 89647 (null) So the directory entries are found, but apart from the one debug output the filenames are not printed! But they are found, as the hlp__lstat() function tells us. Strange, strange ... Sad that the sourceforge hosts have no apr or svn libraries installed, and I think gdb or ddd won't be on them, too ... 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]
Re: fsvs openbsd MacOS 10.4
On Thursday 31 August 2006 00:37 Julien TOUCHE wrote: $ ./fsvs st -d An error occurred: No such file or directory (2) in main: cannot chdir to -d FSVS (licensed under the GPLv2), (C) by Ph. Marek; version trunk:396 a quick way to test if fully functionnal ? The package has a test-suite in it - just call make run-tests. not very far it seems: ... An error occurred at 00:36:55.020: No such file or directory (2) in main: cannot chdir to -m It seems that your getopt() doesn't recognize the options. -d, -m and so on should be interpreted in fsvs.c, to set various flags ... Why doesn't that work for you? Are there man pages for OpenBSD available? (matching your systems' version!) 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]
Re: fsvs openbsd MacOS 10.4
On Tuesday 29 August 2006 20:03 Benjamin M. wrote: Philipp Marek wrote, On 29/08/06 12:46: Does it work now? Yep! But I've a problem with /usr/bin/ld: Undefined symbols but it's probably on my side... will try to take a closer look later... Looks like the linker cannot find the apr libraries. Where are they located? You could try changing the /openpkg/lib in Makefile to something else. Thank you very much for your help! If you've got any more questions don't hesitate to ask. Please tell me whether you got it working! 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]
fsvs openbsd MacOS 10.4
Hello you two! I ran into the same problem on OpenBSD and MacOS. But that should be fixed now, as I found an BSD compatible way. Could you please try and tell me whether that works? Thank you! 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]
Re: fsvs openbsd
Hello Julien! On Sunday 20 August 2006 20:59 Julien TOUCHE wrote: * same thing for configure (presence ok, usability nok) from config.log ... * don't know why make is calling configure ... # make sure they get new timestamps - # configure doesn't touch unchanged files. touch config.h test/Makefile Makefile *** *** The Makefile has been updated. *** *** Please run make again, to build the binary. *** *** Now stopping execution. *** *** gmake: *** [config.h] Error 1 I wrote into the Makefile a check, if the dependent files (Makefile test/Makefile config.h) are *older* than Makefile.in, configure or some other files, it calls configure again. I think you called configure yourself, then started make for compilation - but one file had an older timestamp, so make re-started configure. As configure writes Makefile new (from Makefile.in), it stops at this point, to allow compilation with a current Makefile. So at this point please just start make - then fsvs should get compiled. You can call make run-tests - then after compilation it should do a self-test. Hope that helps! 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]
Re: fsvs MacOS 10.4
On Tuesday 22 August 2006 15:33 Philipp Marek wrote: I now tried for several hours to find the magic combination of preprocessor defines, to get the functions lstat() and fstat() and the struct stat automatically mapped to lstat64() and fstat64() and struct stat64. I tried AC_SYS_LARGEFILE in configure.in and some combinations of -D_GNU_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64 -D_LARGEFILE64_SOURCE=1 -D_LARGEFILE_SOURCE=1 but didn't get it. I read /usr/include/features.h, /usr/include/sys/cdefs.h and /usr/include/sys/stat.h but didn't get any wiser. Does anybody know how to get the automatic mapping 32 - 64bit functions? Well, never mind. The correct way is using *only* -D_FILE_OFFSET_BITS=64 - and nothing else. So the currently committed version has no longer lseek64() and similar, but switches depending on system type. If someone gets problems with files =2GB, please tell. Ben, could you please try again with current trunk? Thank you! 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]
Re: fsvs openbsd
On Friday 18 August 2006 04:51 Benjamin M. wrote: Are you interested by MacOS X (10.4 / Darwin Kernel Version 8.7.0 / PPC)? I can provide you some testing support... I'd like to. Doing compatibility stuff at once would be nice ... PS: fsvs-1.0.12 - all run-tests work flawless on my troublemaking machine... That's good. Thank you for this offer! 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]
