Na Thu, Jun 14, 2007 at 01:36:27PM +0200, Csaba Henk <[EMAIL PROTECTED]> pisal(a): > 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.
i also hit this problem and when i figured out the right config i decided to create darcs2git ;) > 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 sure. voroskoi fetched your hg repo and got the following results: real 0m36.805s user 0m32.150s sys 0m2.549s hg, mutt dir real 0m43.093s user 0m29.613s sys 0m6.080s dr changes, full fw-0.5 repo the hg repo contains more patches and it's faster. i'm not really convinced about this speed though, but i have no idea how much time will it take for 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... we'll see. currently we are forced to do automated tags weekly, and we're at it we create checkpoints for those tags, too. that operation is quite expensive and we have no problems with it. probably it depends on: 1) how frequently it is required to run git gc 2) how much resource will it eat (ie compared to dr tag --checkpoint) > there are some of the demigod category who actually enjoy putting such > things together: > > http://keithp.com/blog/Repository_Formats_Matter.html http://keithp.com/keithp-network.jpg this picture rules :) > Sheesh, tab-indented python code! ;) that's a subject of a flame, too :) at least you don't top-post :) > 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). that's nice, though at the moment we're not able to convert most repos at all, so speed is not the first problem > 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. good to know about this, though i've created a test repo with "normal" and rollbacked patches (having the UNDO prefix) and i was not able to reproduce the problem > There were some problematic patches which failed to apply properly > from my bundles (darcs complaining of a conflict). this is the following case: foo developer tries to push a patch. he fails to push (sigh, i can't write he/she ;/ ) it and then realizes that he need to pull. he resolves the changes and then pushing the two patches togother will be possible. i have no idea how could we solves this properly, it would be good if tailor could do so. a possible solution would be to pack these (usually two) patches into a single commit. i'll also ask the tailor author about what does he think when he'll reply > 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: i know it. though i provided that pulling a few patches (usually two) is enough to avoid a conflict i think something like: n=1 while true do try to pull n patches --dry-run && break n++ done pull n patches should work > I suspect the different ways of resolving these conflicts are to be > blamed for the delta I ended up between darcs and mercurial: this is not ideal but probably these can be easily fixed > 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. we'll see, i hope we can do a clean conversion > Typical panic reaction when first exposed to git :) The long-term > community wisdom, however, tends to prefer making yourself comfortable > with "the git way": things may work out two way: 1) after switching git + 2 weeks, we won't be able to imagine how we lived without dg 2) we'll forget it and just use git, while dg will lay around unused creatating such a tool: 1) was a challenge to me if it's possible to map most daily tasks between two distribued SCM 2) may be helpful till we get used to "the git way" 3) blocks nobody from using the pure git tools :) i just remember muLinux where there were some nice user-friendly dialog-based scripts for newbies (to Linux) and at the end of each script it printed out the commands it used so with time you started not to use the scripts but the given commands :) for everybody: http://wiki.frugalware.org/Git_setup this wiki page tries to map git commands to each darcs command. it's the base of dg. feel free to correct/improve it, i've recently replaced the last "need to check" script on that page :) > http://tytso.livejournal.com/29467.html these links are great :) randomly picking a few sentences: "I don't recommend Cogito, since git 1.5 is significantly more usable, and I've always found Cogito to be more confusing that just using stack git." i completely agree about git docs: yes and no. sure, many switches are not documented but it seems that finding out how to do tasks we do with darcs was possible. ok, i recetly joined the #git irc channel and i got help from there, too > http://article.gmane.org/gmane.comp.version-control.mercurial.general/323 i like here this "the scm is for the project and not the project is for the scm" approac. forcing ourselves to change our development model just for git would be bad. i mean the kernel-style "if Linus goes to holiday there is no merge for one week" versus our "cvs-like" model (most developers have direct write access) > http://wiki.freebsd.org/GitConversion really nice articly. i just understood how git-cherrypick works while reading that page :) and also it points out a problem: when users doing a repoman upd, they rsync the _darcs/current dir. with git, this is not easily possible. this covers two features: 1) avoid downloading the full history (they just need a snapshot) this is possible: git-archive --remote=url --format=tar HEAD |tar xf - 2) avoid downloading a full snapshot (like rsync does) i have no idea how would this possible. old frugalware users may remember that we used to force users to use darcs get/pull but because of some (speed and not space!) problems, we switched to rsync. we can see what's better: git pull && git gc or git-archive. the first will be probably fast, the later will require (i don't know how much) less space VMiklos -- developer of Frugalware Linux - http://frugalware.org
pgpuXfAERNTFu.pgp
Description: PGP signature
_______________________________________________ Frugalware-devel mailing list [email protected] http://frugalware.org/mailman/listinfo/frugalware-devel
