On Wed, Jun 13, 2007 at 11:42:05PM +0200, VMiklos wrote: > voroskoi recently made a blog post about this: > > http://blogs.frugalware.org/voroskoi/2007/06/09/problems_with_darcs_but_there_is_nothing
Nice to see most of our conclusions agree... not _all_ of them, though :) > wow, it's nice. i know tailor and i used it already for converting > smaller repos. (there is a small script available at > http://darcs.frugalware.org/repos/vmexam/darcs/darcs2git which > simplifies the task). the first problem was the accents in the commit > messsages, i've created a path for this and it's alrady in tailor's > darcs. it's surprising that you were able to convert -current to hg as > the author said my problem affected any conversion where the source is > darcs Dunno, maybe when I did the conversion, this fix was already included in tailor. As I said, I've met several problems, but I had no problem with the encodings. Regarding my failure with git conversion: yeah, I used a Tailor config similar to the one in darcs2git. I don't know why it didn't work. It failed with strange errors at the bootstrap stage by seeing darcs whining that xyz is not a darcs repo. Apparently my darcs instance didn't like the simultaneous presence of .git and _darcs. I worked this around with a wrapper script which renamed .git, then called darcs, then renamed back the git directory to .git -- still darcs whined elsewhere and I really got fed up at this point. > on the other side, it's interesting: > > $ time lynx -dump > 'http://mercurial.creo.hu/repos/frugalware-current-hg-experimental/?rev/fd74925ad115' > >/dev/null > > real 0m13.247s > > $ time lynx -dump > 'http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=frugalware-current;a=darcs_commitdiff;h=20070507182839-f6986-80755f3e0bdef5d584a984e5c4cf86cb6a3fdee0.gz;' > >/dev/null > > real 0m0.255s > > i picked a random patch, maybe it's darcsweb's caching mechanism, who > knows. i know that hg should be faster than darcs, it's just interesting > :) I guess hg spends some time with hunting down all the diffs related to the cset from its indices, while darcs has the patch stored as is. Still I agree that hg could perform here a bit better... though its within the usability barrier. Regarding darcs, trying to generate a file revision history shows its darker sides: http://darcs.frugalware.org/darcsweb/darcsweb.cgi?r=frugalware-current;a=tree;f=/source/devel/ccache > i played with smaller repos, during the conversion tailor bails out with > an error when converting the first tag at some repos. i've mailed the > tailor maintainer, but this problem is not as clear to me as the accent > one was (there all the problem was that darcs did not generate a valid > xml) I didn't experience this, probably because of my non-standard conversion method (details below). > as voroskoi mentioned, darcs is fine, our only big problem with it is > its speed. as you and he mention, too the two promising alternatives are > hg and git. there were a benchmark about bzr, hg and git about > converting the mozilla repos and there it has been pointed out that git > is faster. since our problem was speed, i started to play with git. I'd have one worry about git if I were to host a project of the size of Frugalware: the need of repacking. If you don't do that, your repo size goes up to unspeakable quantities. If you do that regularly, your repo size will be close to the theoretical lower bound. But doing that properly on a public repo needs a subtle server side infrastructure... there are some of the demigod category who actually enjoy putting such things together: http://keithp.com/blog/Repository_Formats_Matter.html but I'm not in that category (neither demigods, nor chronic mazochists), and I have the impression that you are neither there (but enlight me if I'm wrong). OTOH, Mercurial's cumulative index files just work. > due to the same reason (we like how darcs works), i've started to write > a wrapper around git, it's like cogito, but it's primary focus is > behaving like darcs. it's available at > > http://darcs.frugalware.org/repos/vmexam/python/dg.py > > currently what worth mentioning is that dg record and dg revert more or > less works like in darcs, with full cherry-pick support Sheesh, tab-indented python code! ;) > 1) we're working with the tailor author to be able to convert some of > our problematic repos from darcs to git Let me then join the party. Most issues I met with were on the darks side, so you can use my experience even if you target at git. The three big issues were 1) sluggish darcs pull; 2) tailor miscomputed the darcs patch hashes; 3) conflict resolution. Regarding 1): contrary to pull, "darcs apply" works at a useable speed. So I wrote a ruby script which generated darcs bundles for all of the patches in the repo and used darcs through a wrapper script which invokes darcs apply mybundles/<hash-id> when its called with arguments `pull --match "hash <hash-id>"` (and simply delegates to darcs otherwise). Regarding 2): there are two subcases. a) bogus commits in the repo, b) tailor is not reproducing faithfully the darcs hashing method. a) was as follows: when you do a "darcs undo", you get a patch name in the xml log like "UNDO: whatever". Such patches are special, and Tailor cleverly identifies these by the starting "UNDO:" in the patch name. However, apparently you had some regular patches the name of which starts with "UNDO:", eg.: http://mercurial.creo.hu/repos/frugalware-current-hg-experimental/?rev/7dbf7135f50c And this confused tailor. (Luckily, you gave up this practice pretty early.) I manually found out the proper hash value and then sedded the state file (upon this, I have had felt better if the state file format had been YAML or some other human-friendly thing as it's planned...). b) cases are simply tailor bugs, I will aptly forward my respective fixes upstream. Regarding 3): There were some problematic patches which failed to apply properly from my bundles (darcs complaining of a conflict). For these, I falled back to the standard pull method which somehow was clever enough to succeed (well, on _one_ of the machines I tried the conversion on it succeeded; on the other, darcs just hung [the dreaded exponential explosion darcs bug: http://article.gmane.org/gmane.comp.version-control.darcs.user/10796 ??], albeit both darcs instances were of release 1.0.8). I suspect the different ways of resolving these conflicts are to be blamed for the delta I ended up between darcs and mercurial: ! source/devel-extra/perl-gnome2/FrugalBuild ! source/devel-extra/perl-gtk2/FrugalBuild ! source/devel-extra/wxpython/FrugalBuild ! source/lib-extra/clanlib/FrugalBuild ! source/lib-extra/clanlib/clanlib-0.7.8-gcc41.patch1 ! source/lib-extra/clanlib/clanlib-0.7.8-refreshfix.patch0 ! source/xapps/gaim/FrugalBuild ! source/xapps/gaim/musicmessaging-use-usr.patch ! source/xapps/gaim/perl-fix.patch ! source/xapps/scim/FrugalBuild ! source/xapps/scim/scim.sh ! source/xlib/qca/FrugalBuild ? index.cgi ? source/devel/mono/rc.mono ? source/gnome-extra/perl-gnome2/FrugalBuild ? source/gnome/libgalago/FrugalBuild ? source/network/apr/FrugalBuild ? source/xapps-extra/ogle/FrugalBuild ? source/xapps-extra/ogle/alsa-fix.patch ? source/xapps-extra/ogle/ogle-0.9.2-gcc4.patch0 ? source/xapps-extra/qemu/FrugalBuild ? source/xapps-extra/qemu/README.Frugalware ? source/xapps-extra/qemu/rc.qemu ? source/xapps-extra/qemu/rc.qemu-hu.po ? source/xapps-extra/qemu/rc.qemu.pot ? source/xapps-extra/scim/FrugalBuild ? source/xapps-extra/scim/scim.sh ? source/xapps-extra/sylpheed/FrugalBuild ? source/xapps-extra/wxpython/FrugalBuild ? source/xapps/pidgin/FrugalBuild ? source/xlib-extra/clanlib/FrugalBuild ? source/xlib-extra/fox/FrugalBuild ? source/xlib-extra/fxruby-1.4/FrugalBuild ? source/xlib-extra/fxruby/FrugalBuild ? source/xlib-extra/perl-gtk2/FrugalBuild ? source/xlib-extra/qca/FrugalBuild ? source/xlib-extra/wxgtk/FrugalBuild That's why I am interested in seeing how the git conversion works out: maybe git's ways (or tailor's git instrumentation) will yield a more accurate result. If not, then the conversion is to be redone with more hand-muckling around the critical patches. Yuck. > 2) it seems that git has very lowlevel tools which worth a frontend, and > we'll see how easy/hard is to create one Typical panic reaction when first exposed to git :) The long-term community wisdom, however, tends to prefer making yourself comfortable with "the git way": http://tytso.livejournal.com/29467.html http://article.gmane.org/gmane.comp.version-control.mercurial.general/323 http://wiki.freebsd.org/GitConversion (look for the words "cogito", "1.5"). Csaba _______________________________________________ Frugalware-devel mailing list [email protected] http://frugalware.org/mailman/listinfo/frugalware-devel
