compact repository (many files)
Hello, I have here a personal Subversion repository hosted on my university account (for easy access from everywhere via SSH). (Its format is a 1.5 FSFS, from the information in the meta-files.) I'm now to revision 2529, which means the whole repository has 5098 files (most of them in db/revs and db/revprops), and which each new revision I get two more files. (The whole repository is about 45 MB big, but that's not the matter here.) The problem now is that I have a quota limitation of 3 files here (additionally to a size limit), and my svn repository fills now about 1/6 of this, steadily growing, forcing me to delete other files ... Is there any way to reduce the file number of the repository without throwing away information? As in, throw the changes in revisions 0 ... 999 together in one file (and this way even safe some space for better compression)? (I don't care for worse performance, as those old revisions are used only very seldom.) I found nothing about this by extensive googling so I assume such a function is not yet implemented. Is this really a new idea, or was it discussed before and rejected? Or is there a simple workaround? Paul
Re: compact repository (many files)
Mark Phippard wrote: > On Wed, May 26, 2010 at 11:53 AM, Paul Ebermann wrote: [...] >> Is there any way to reduce the file number of the repository without >> throwing away >> information? As in, throw the changes in revisions 0 ... 999 together in one >> file (and >> this way even safe some space for better compression)? (I don't care for >> worse >> performance, as those old revisions are used only very seldom.) >> >> I found nothing about this by extensive googling so I assume such a function >> is not yet >> implemented. Is this really a new idea, or was it discussed before and >> rejected? Or is >> there a simple workaround? > > Subversion 1.6 includes the svnadmin pack command which will convert > every 1000 revisions into a single revision file. Ah, nice to now, so I now only have to wait (or lobby) for the next software update on one accessible computer. (The server works with older clients, IIRC.) (Thanks also to the other answerers.) (It shows I don't find the right search words.) > It does not pack > the revprops though, so it will only save you about 2000 files instead > of 4000. I think packing the revprops would (from a space viewpoint) be even more useful than packing the revisions, since most of these are quite small (similar) text files. Statistics: only 91 of those have a size of more than 150 bytes, the combined size (including "file: size" like lines for each) is 356 KB, while they now use 2.56 MB due to block size of 1K (= 7 times the space), even without any compression. And I would save those 2000 files. Paul
Re: compact repository (many files)
B Smith-Mannschott wrote: > On Wed, May 26, 2010 at 19:07, Paul Ebermann wrote: >> I think packing the revprops would (from a space viewpoint) be even more >> useful than >> packing the revisions, since most of these are quite small (similar) text >> files. >> >> Statistics: [...] > > True, but revprops are mutable, while revs are immutable. OK, this explains it a bit. > That said, > packing of revprops has been implemented on trunk and will be coming > with 1.7. All my wishes come true :-) > You might consider the option using bdb instead of fsfs for your > repository. I wouldn't normally prefer bdb, but it does create far > fewer files than fsfs. I read[1] bdb does not work reliable on NFS, and my repository as on such a file system (and I can't really change this). Or does this reliability problem only concerns access from multiple hosts? (I in all cases access the repository via svn+ssh with the same server host, if this matters.) Paul [1]http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.reposadmin.basics.backends.bdb
Re: svnserv + ssh + ldap
Nico Kadel-Garcia wrote: >> $ export `gnome-keyring-daemon` > > Good, but ouch. Let's try adding a bit of rigor, shall we? First, > before running such a daemon, always check that it actually exists, > where you expect it to exist. Running random commands that will handle > passwords which may have been replaced by who knows what somehwere in > your $PATH is always a bad idea. So let's use this instead: > > if [ -x /usr/bin/gnome-keyring-daemon ]; then > export `gnome-keyring-daemon` > fi Shouldn't this be like this? if [ -x /usr/bin/gnome-keyring-daemon ]; then export `/usr/bin/gnome-keyring-daemon` fi Otherwise there is not really an improvement to before, only a protection against "file does not exist". Paul
Re: svn checkout - special characters in file name are not encoding properly
Vincent Lefevre wrote: > On 2010-08-10 20:59:00 +0200, Stefan Sperling wrote: > >> The native encoding is determined by the locale, but that does not matter. >> The point is that, wherever encoding configuration happens to come from, >> if the configured encoding cannot represent the character string stored >> as UTF-8 in the repository, what is Subversion supposed to do? It cannot >> really do anything with a filename it cannot represent in the character >> set configured by the user, other than throwing an error. > > For filenames stored on disk, they (all of them) can be encoded using > UTF-8. Remember, filenames on a POSIX system are just sequences of > bytes. For what is output to the terminal, non-representable > characters can be displayed by a replacement characters such as "?". > This can still be better than an error. The thing is, users are using other tools than SVN to work with the files, too. So if I look at my directory with a file manager, I want my filenames to be readable (and renameable). The idea is that usually the user uses for one working copy always the same locale for all tools, so all filenames look same. Of course this is not possible if some characters in the repository simply do not exists in our current locale charset. Maybe Subversion (or APR) could support (optionally by command-line-flag and/or config option) some reversible replacement encoding, like "b...@e4@lle.txt" for "Bälle.txt" if the current charset does not contain "ä". (And such-named files would be allowed for add/import etc., resulting in "Bälle.txt" in the repository.) (This @-encoding is only an example, not really a proposal - this could conflict with other uses of @.) Paul (who uses a UTF-8-locale personally)
Re: svn checkout - special characters in file name are not encoding properly
Vincent Lefevre wrote: > On 2010-08-11 13:51:18 +0200, Stefan Sperling wrote: >> On Wed, Aug 11, 2010 at 12:35:59PM +0200, Vincent Lefevre wrote: >>> Yes, and this is another reason why the solution chosen by Subversion >>> doesn't work well. For instance, GNOME always uses UTF-8 for filename >>> encoding. >> You might as well argue that Subversion's solution works well but >> GNOME's solution does not. > > That's wrong. GNOME let's me to use any locale in shell sessions. > Subversion doesn't. Yes, but GNOME does not allow using any locale in a file manager session (or, it ignores the locale in the filemanager session, while the command line tools do not). (KDE is similar, for my experiments.) >>> So, if the user uses ISO-8859-* locales (for shell sessions), >>> one gets inconsistencies. >> So don't use GNOME if you don't want your filenames encoded in UTF-8, > > I meant: one gets inconsistencies between GNOME and Subversion. > >> or don't use a non-UTF-8 locale when working with files you want to >> use from GNOME. Problem solved. > > You're forcing the user to use a UTF-8 locale. Unacceptable. No, GNOME forces the user to use a UTF-8 locale, if ls, rm, cd and other command line tools are to show/accept the same name as the GNOME file manager. Subversion here simply behaves as any other Unix command line tool, it seems, with the additional gotcha that it does not only use input from and output to terminal and file system, but also from/to the repository. Paul
