| gour | jelmer: ping | 08:37 |
|---|---|---|
| gour | jelmer: now is see the proble, original fossil repo has size of 418M, but it achieves extreme compression-ratio of 1612.1 and the artifact-sizes from its 'dbstat' cmd shows: 8,935,093,232 total, so when i do fast-export from fossil to git, the exported size is 8.4G which, indeed, exceeds the size of the tmpfs...it seems i've picked the wrong repo for testing purposes :-) | 08:42 |
| gour | will try now with something smaller, iow. with less compression-ration | 08:42 |
| gour | now, with a smaller repo, i get another error: https://paste.fedoraproject.org/paste/E~5mj4bg71qo-UE5WokA5w | 08:50 |
| jelmer | gour: is that from pip or trunk? | 09:53 |
| jelmer | Pip is many months old at this point | 09:53 |
| gour | jelmer: pip | 10:10 |
| gour | what would be the most clean way to install from the trunk, or maybe i should do pip-install from the trunk | 10:11 |
| jelmer | just 'bzr branch lp:brz; cd brz; ./setup.py install' | 10:14 |
| gour | maybe it's from the trunk (installed with: pip2.7 install --user bzr+lp:brz), version shows: breezy (3.0.0.dev1), so how can i know? | 10:14 |
| jelmer | I don't think it provides a good way to know if you install from pip | 10:23 |
| gour | correct. install from the trunk shows same version...let me try the same experiment... | 10:36 |
| gour | jelmer: same as before - see: https://paste.fedoraproject.org/paste/FacFQCy8mADdLbDiVI46ig | 10:40 |
| === gour_ is now known as gour | ||
| Walex | oh well very happy that Breezy is a thing... | 17:39 |
| Walex | I am compiling a table of "features" of various VCSes, and I am wondering: in the repo format "2a" how many files there are in the store? One per commit like 'git'? One per tracked files like in Mercurial? One per repo like in monotone? | 17:40 |
| Peng | It's similar to storage using Git's pack files. | 18:40 |
| Peng | Recent revisions will be in a pack file plus 4 index files. Older revisions will have been autocompressed into larger and larger files. | 18:41 |
| Peng | So maybe a few dozen files, plus small metadata files. | 18:43 |
| Peng | But it probably varies depending on repository usage patterns. | 18:43 |
| Walex | Peng: many thanks, so it is basically per-commit, plus packing. to consolidate many commits in a single file. | 22:03 |
| Walex | BTW the reason why I ask is that one of the crucial features of a VCS is the storage structure. For example Mercurial creates two file per every file that ever existed in the working directory, so large projects end up with a colossal number of files, even workse than Subversion... | 22:50 |
| Walex | BTW as a suggestion now that Canonical seems to be no longer sponsoring Bazaar, Breezy could become "GNU Breezy", which would help. | 23:01 |
| Peng | Bazaar's storage has been pretty good for like ten years. ;-) | 23:02 |
| Peng | Dunno what them other VCSes been up to. :D :D | 23:02 |
| Walex | Peng: :-) | 23:02 |
| Walex | Yes, but format 2a should have been publicized more widely | 23:02 |
| Walex | I remember reading the blog post with the speed tests on the OpenOffice.org repo and they are quite good | 23:03 |
| Peng | It's not exactly per revision. It's per thing-that-happened. If you pull 10 revisions, they'll be stuffed in one pack, it won't generate 10 packs simultaneously. | 23:03 |
| Walex | Peng: ah yes, I might have veen using "revision" loosely. per commit? | 23:04 |
| Peng | same thing | 23:04 |
| Walex | Peng: but it is pretty good indeed, possibly better than the 'git' object store, which really really needs to be repacked... | 23:04 |
| Walex | BTW sadly the killer feature is the ability to se the '.git' object store directly. That's amazing killer feature. | 23:05 |
| Walex | I have watched Martin Packman's video and his point that 'bzr' has a user interface for people *and* can use '.git' (and has a competitive native format) is quite strong. | 23:06 |
| Peng | This is kind of only of historical interest, but Bazaar went through a number of different storage formats, starting off with what might not have been very good, and ending with a good format. Git and Mercurial kind of started with pretty-good formats and have been loath to change them. | 23:07 |
| Walex | BTW the /topic should really really be in the /topic and so J Elmer's blog post. | 23:07 |
| Walex | Peng: I am an old timer (I started with SCCS, used it extensively) and I have followed Bazaar since the very first days. And ther others. | 23:08 |
| Walex | BTW the video URL should really really be in the /topic and so J Elmer's blog post. | 23:08 |
| Walex | Peng: I sould strongly dispute that the Mercurial storage format is good. | 23:09 |
| Walex | Peng: that's a developer's point of view, for small repos. I am nowadays mostly a sysadmin and lots and lots and lots of small files are a very big problem. | 23:09 |
| Peng | Heh. D: | 23:10 |
| Walex | Peng: things like that are for example very, very slow to 'fsck'. | 23:10 |
| Walex | Peng: hosting a Subversion repo, with one storage file per original file is already a pain, hosting Subversion checkouts is even worse, hosting Mercurial is horrifying. | 23:11 |
| Walex | Developers never have to fsck or backup or index their repos and checkouts. | 23:11 |
| Walex | Ahhhh I have another secondary question... | 23:12 |
| Walex | a bit of too detailed perhaps... | 23:12 |
| Walex | still on storage. | 23:12 |
| Walex | so, a point made by the developer of 'monotone' who has switched to 'git' but who thinks that Mercurial is better, is that multiple 'monotone' checkouts can share the same storage directory '.mtn', while with 'git' the 'git' directory must be copied per checkout. What's the current story woh the '2a' format as to that. | 23:14 |
| Peng | Bazaar supports shared repositories. | 23:16 |
| Walex | Peng: except when they are 'git' one I guess... | 23:17 |
| Peng | you do "bzr init-repo" in a directory, and any Bazaar branches in child directories will put their stuff in that repository, instead of maintaining their own repositories. | 23:17 |
| Peng | It works well with Bazaar's branch-per-directory model. | 23:17 |
| * Walex was thoroughly amazed when I could just go 'bzr log' in a 'git' cloned repo. | 23:18 | |
| Walex | Peng: yes, I had hoped so. | 23:18 |
| Walex | BTW my very drafty draft blog post on VCSes and Breezy: http://localhost/blog/drafts2.html?180106#180106 | 23:20 |
| Walex | and my very old table of comparison that I am slowly updating: http://localhost/blog/drafts2.html?110817#110817 | 23:21 |
| Walex | very drafty draft too. | 23:21 |
| Walex | Ah other question for my table -- how "bad" is 'bzr'/'brz' for large binary files? I guess same as 'git'... | 23:25 |
| Walex | there is no mention of Breezy on Wikipedia yet | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!