| jelmer_ | workthrick: that's not really possible without breaking all git imports in existance or changing the way nested trees work | 02:41 |
|---|---|---|
| === jelmer_ is now known as jelmer | ||
| workthrick | jelmer: can't you make it happen only on new imports, and/or only if you opt-in with an option? | 04:43 |
| bignose | Attempting to work with Gitorious repositories | 10:07 |
| bignose | $ bzr branch --bind git://git@gitorious.org:dive-into-html5/dive-into-html5.git devel/ | 10:07 |
| bignose | bzr: ERROR: The remote server unexpectedly closed the connection. | 10:07 |
| === tomaw_ is now known as tomaw | ||
| bignose | I can clone it with Git, but then attempting to branch locally from a Git repository fails | 10:08 |
| bignose | probably because I don't know how to tell Bazaar that the local directory is a Git repository. | 10:08 |
| bignose | same failure if I try ‘git+ssh’ | 10:09 |
| bignose | bzr branch --bind git+ssh://git@gitorious.org:dive-into-html5/dive-into-html5.git devel/ | 10:09 |
| gour | bignose: have you tried cloning something from github? i also get error with the above branch | 10:37 |
| maxb | bignose: You have a colon between the hostname and the path. That's not an URL | 11:06 |
| bignose | maxb: thanks. I was (obviously) cribbing from a URL designed for use with Git. | 11:13 |
| bignose | jelmer: now I get “AttributeError: 'RepositoryFormat2a' object has no attribute 'supports_full_versioned_files'” | 11:13 |
| maxb | Huh. It's news to me that git doesn't use standard URLs too | 11:13 |
| bignose | from /usr/lib/python2.6/dist-packages/bzrlib/plugins/git/fetch.py | 11:13 |
| bignose | maxb: I'm sure it does, but being Git, it probably supports a zillion different syntaxes also. | 11:14 |
| maxb | bignose: I'd suggest version skew between bzr core and the bzr-git plugin | 11:14 |
| * gour suggests (most of) people to move to bzr :-) | 11:14 | |
| lifeless | bignose: strictly speaking, its not a URL, whether git accepts it or not | 11:15 |
| bignose | lifeless: is this a “URI versus URL” distinction? | 11:16 |
| lifeless | no | 11:16 |
| bignose | 'cos the ‘git+ssh://git@gitorious.org/dive-into-html5/dive-into-html5.git’ looks like a URI to me | 11:16 |
| bignose | I'm pretty sure it meets the URI standard also | 11:17 |
| lifeless | thats a url | 11:17 |
| lifeless | git+ssh://git@gitorious.org:dive-into-html5/dive-into-html5.git isn't | 11:17 |
| bignose | lifeless: yes, agreed. | 11:17 |
| lifeless | per std66 | 11:17 |
| lifeless | the new error you are getting | 11:17 |
| bignose | my point being that while I'm sure Git accepts standard URIs, I'm sure it *also* accepts loads of things which aren't URIs | 11:18 |
| lifeless | is a version skew in the bzr-git <-> bzrlib version you're working with | 11:18 |
| bignose | and those creep into documentation (such as the “how to branch this repo” instructions on Gitorious) | 11:18 |
| bignose | okay. [insert standard until-OpenID-relying-party-support-on-Launchpad-no-bug-report-from-me] I hope it can be reported and fixed. | 11:19 |
| lifeless | jelmer is busy refactoring a tonne of stuff to get better test coverage | 11:20 |
| bignose | great. | 11:20 |
| lifeless | (making good use of his full time work on bzr ;)) | 11:20 |
| bignose | I'm madly impressed with Jelmer's work of late | 11:20 |
| lifeless | one of the things is that he's adding flags indicating what features the repository implementations handle | 11:20 |
| lifeless | anyhow | 11:21 |
| lifeless | point is, this is transient | 11:21 |
| lifeless | next stable bzr release will make the bzr-git version work | 11:22 |
| gour | 2.4? | 11:23 |
| lifeless | something like that | 11:26 |
| maxb | Yikes, importing the linux kernel into an UDD branch from scratch looks like it's going to take days | 12:04 |
| maxb | 8 hours runtime, and it's still not done hardy yet | 12:05 |
| spiv | maxb: trying with trunk bzrlib? | 12:09 |
| spiv | I have a suspicion that jam's speed improvements will probably help a least a bit there, maybe a lot. | 12:10 |
| maxb | hmm, actually this machine is still on 2.3.x | 12:10 |
| jelmer | bignose: that issue has been fixed in bzr-git trunk a while ago.. where are you getting your bzr-git? | 13:20 |
| bignose | jelmer: Debian, as usual. | 13:31 |
| bignose | bzr-git 0.6.0+bzr1223-1 | 13:32 |
| jelmer | bignose: I'll upload a new version to sid | 13:44 |
| bignose | jelmer: a new release? | 13:47 |
| jelmer | new snapshot | 13:47 |
| bignose | hmm. isn't such a fix worth at least a point release? | 13:47 |
| jelmer | bignose: the regression isn't actually in any release | 13:47 |
| * bignose laments that people seem to avoid releases more often these days | 13:47 | |
| bignose | ah okay. | 13:47 |
| jelmer | I don't want to do a new release for every single bugfix :) | 13:48 |
| bignose | jelmer: congrats on what appears to be some pretty awesome improvement to Bazaar performance | 13:48 |
| jelmer | bignose: blame jam :) | 13:49 |
| bignose | ah, hm, wrong “J'm” person :- | 13:49 |
| bignose | ) | 13:49 |
| jelmer | :) | 13:49 |
| bignose | jelmer: well, congrats on making my current job far nicer: ‘bzr-svn’ saves me heaps of frustration | 13:50 |
| jelmer | thanks - that's great to hear | 13:51 |
| maxb | Someone declined bzr-core from bzr-codereview-subscribers | 16:18 |
| jelmer | maxb: see the email | 16:33 |
| jelmer | maxb: Aaron did | 16:33 |
| maxb | yes | 16:33 |
| maxb | But then I figured out how to make it a member myself anyway | 16:33 |
| maxb | :-) | 16:33 |
| maxb | jelmer: By the way, what's going on with the dulwich trunks? ~vcs-imports/dulwich/trunk and ~dulwich/dulwich/trunk have diverged | 16:35 |
| jelmer | maxb: should be fixed now | 16:55 |
| maxb | thanks | 16:55 |
| jelmer | hmm, the integration to make dulwich use bzr's ssh integration seems busted | 17:04 |
| maxb | jelmer: I'm still occasionally running into BzrCheckErrors manipulating dulwich branches, relating to the improper dpush-ing that I've mentioned in the past. What do you think about doing this: | 17:21 |
| maxb | Erase the published shared repository on samba.org and replace it with one not suffering from the problem. Rename the old ~dulwich/dulwich/trunk to trunk-broken, and create a new one. This would at least prevent the bad data from spreading further, though it won't help with the cleanup. | 17:21 |
| jelmer | maxb: I'd like to get rid of the remaining inconsistent parent issues in bzr-git before doing that | 17:25 |
| maxb | Well, maybe just rename ~dulwich/dulwich/trunk to trunk-broken for now, then to communicate that people shouldn't be using it? | 17:26 |
| === yofel_ is now known as yfel | ||
| === yfel is now known as yofel | ||
| === tomaw_ is now known as tomaw | ||
| lifeless | jelmer: maxb: what are the symptoms of that bad dpush ? | 21:45 |
| lifeless | bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:d34f39faee56e120a83e7cec4fe01c4fd5fd32f6',)] one of them ? | 21:45 |
| jelmer | lifeless: yes | 21:55 |
| lifeless | ah | 22:03 |
| lifeless | so this has broken launchpad's deployment now | 22:03 |
| lifeless | a) how do we fix? | 22:03 |
| lifeless | b) how do we stop it breaking it again ? | 22:04 |
| lifeless | jelmer: ^ | 22:04 |
| lifeless | wgrant: ^ may be useful for you later today | 22:04 |
| lifeless | heh | 22:06 |
| maxb | lifeless: Hmm. I usually get "missing text keys" when I'm being bitten by this dulwich issue | 22:08 |
| mgz | is bugs.debian.org the upstream tracker for etckeeper? | 22:17 |
| lifeless | I don't thinkso | 22:17 |
| mgz | I'm not seeing anything on Joey Hess' webpage about where he wants bug reports | 22:17 |
| mgz | I imagine there's a file in the package that tells you | 22:18 |
| elmo | mgz: bugs.debian.org, I'd imagine | 22:18 |
| mgz | we've got a report against bzr over non-ascii filenames that seems to be being hit because etckeeper has some bogus environment for a cron script | 22:19 |
| mgz | there's an existing bug entry for the issue our end, but it looks like it's worth filing something for the other part too | 22:21 |
| mgz | might just be a problem with the guy's system but I don't know enough about locale weirdnesses on nix to tell | 22:24 |
| lifeless | maxb: hi | 22:26 |
| lifeless | nvm | 22:28 |
| lifeless | actually yes, need to check | 22:31 |
| lifeless | maxb: why are bzr and bzr-core members of bzr-codereview ? | 22:31 |
| mgz | it's a temporary measure until all the people who want to subscribe have a chance to | 22:31 |
| maxb | lifeless: It's a transitional measure, did you see my email on bazaar@l.c.c ? | 22:32 |
| lifeless | we only need -core | 22:32 |
| lifeless | bzr is a member of -core | 22:32 |
| lifeless | with -core and bzr both non-open, we should change the owner to be -core too | 22:33 |
| lifeless | [or change it to be -council, but -council perhaps wants more members] | 22:33 |
| maxb | Actually, having stared quite a bit at how the teams are configured in preparing for this, I'm planning to propose deleting ~bzr-core eventually | 22:33 |
| lifeless | we can do a merge into ~bzr at that point | 22:34 |
| maxb | True | 22:34 |
| maxb | So: short-term: Once one week is up, I will remove ~bzr(-core) from ~bzr-codereview-subscribers | 22:35 |
| maxb | Long-term: I want to continue working on obsoleting the existence of ~bzr-core | 22:36 |
| lifeless | man | 22:39 |
| lifeless | putting together custom pc's got -hard- over the last 10 years | 22:39 |
| lifeless | but no mainstream vendor seems to want to sell a 32gb config :( | 22:40 |
| fullermd | It's awful hard to do that on client hardware. | 22:40 |
| lifeless | fullermd: awful hard to do which bit? | 22:40 |
| lifeless | jelmer: : | 22:40 |
| lifeless | 08:45 < lifeless> jelmer: maxb: what are the symptoms of that bad dpush ? | 22:40 |
| lifeless | 08:45 < lifeless> bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:d34f39faee56e120a83e7cec4fe01c4fd5fd32f6',)] one of them ? | 22:40 |
| fullermd | 32 gig (of RAM, I'm assuming) | 22:40 |
| lifeless | 08:55 < jelmer> lifeless: yes | 22:40 |
| lifeless | 09:03 -!- BasicOSX [~BasicOSX@c-75-73-131-27.hsd1.mn.comcast.net] has joined #bzr | 22:41 |
| lifeless | 09:03 < lifeless> ah | 22:41 |
| lifeless | 09:03 < lifeless> so this has broken launchpad's deployment now | 22:41 |
| lifeless | 09:03 < lifeless> a) how do we fix? | 22:41 |
| lifeless | 09:04 < lifeless> b) how do we stop it breaking it again ? | 22:41 |
| lifeless | fullermd: i-2600 + 4*8GB DDR3 sticks | 22:41 |
| lifeless | 09:04 < lifeless> jelmer: ^ | 22:41 |
| lifeless | 09:04 < lifeless> wgrant: ^ may be useful for you later today | 22:41 |
| fullermd | Yeah, and 8 gig DIMMs mean 4Gb DRAM chips, which are still quite rare. | 22:41 |
| lifeless | fullermd: http://ark.intel.com/Compare.aspx?ids=52213,52214,52215 | 22:41 |
| fullermd | (or buffered DIMM's, in which case you're out of the client world) | 22:42 |
| fullermd | Sure, that's what it's rated for. Doesn't mean the DIMMs are at all easy to come by. | 22:42 |
| lifeless | fullermd: sure | 22:42 |
| fullermd | (and I'm awful suspicious of that sort of 'memory size' rating on a memory controller anyway...) | 22:43 |
| fullermd | 2Gb DRAMs are relatively common now, which gives you 4 gig [unbuffered] DIMM's. If you go to a 1366 socket or wait for 2011, that'll give you 3*2 of those, for 24 gig at least. | 22:44 |
| lifeless | fullermd: it is 2011 | 22:44 |
| fullermd | Socket 2011. | 22:44 |
| lifeless | ah | 22:44 |
| fullermd | Q4 this year maybe? Dunno offhand. | 22:44 |
| fullermd | I don't pay that much attention to schedules for Intel client chips, since they're out of my to-buy list. | 22:45 |
| lifeless | the 3* is the gutfeld stuff isn't it ? | 22:45 |
| lifeless | anyhow, I want 4GB/thread | 22:45 |
| fullermd | The top Nehalems and Westmere are tri-channels. The tri Sandy Bridges are the 2011 stuff. | 22:45 |
| lifeless | yeah, I'm replacing my i920 - a trichannel | 22:46 |
| jelmer | lifeless: how has this broken launchpad deployment? | 22:46 |
| fullermd | Of course, I'm pretty sure they're all lower single-thread perf than the 2600. | 22:46 |
| lifeless | jelmer: see buildbot | 22:46 |
| lifeless | jelmer: what happens on buildbot will happen to the deploy path | 22:46 |
| lifeless | fullermd: the 920 has 4 cores 8 threads but w/6GB of ram as soon as I start to throw parallel work at it it thrashes :( | 22:47 |
| jelmer | lifeless: ah, hadn't seen that. I'll look into it tomorrow | 22:47 |
| lifeless | jelmer: well we kinda have to fix it today | 22:48 |
| lifeless | jelmer: or we'll mess up the schedule for db deploy this week | 22:48 |
| lifeless | jelmer: so if you want evidence captured or whatever, say so now ;) | 22:48 |
| lifeless | otherwise I suspect wgrant/spm are going to get rm-ing on the symptoms | 22:48 |
| lifeless | fullermd: so whats the cl7/cl9 refer to ? | 22:51 |
| maxb | Number of clock cycles it takes the DRAM to set up for reading an address, I think? | 22:52 |
| * maxb wonders if we *really* need an UDD import of the kernel :-/ | 22:52 | |
| maxb | This Soyuz duplicate .orig.tar.gz is proving irksome | 22:53 |
| lifeless | skip that revision? | 22:53 |
| jelmer | lifeless: I'll see about having it cleaned up now | 22:54 |
| lifeless | jelmer: thanks, but there won't be a losa around for another hour or so - rather than working your weekend, you might like to just note what evidence you'll want kept | 22:54 |
| jelmer | lifeless: I have all that, I'd just rather get it cleaned up than to get that particular MP reverted | 22:55 |
| lifeless | jelmer: Oh, I wasn't thinking reversion | 22:56 |
| lifeless | rather widespread rm -rf of the working area and fresh pull | 22:56 |
| lifeless | s | 22:56 |
| lifeless | I wonder if you can shove a server 240 pin 8gb dimm into a 'client' motherboard | 22:57 |
| lifeless | successfully | 22:57 |
| jelmer | lifeless: Ah, sorry - I thought you meant removing the revision in question. In that case I won't worry. | 22:59 |
| lifeless | that wouldn't be my first choice as it would require another 10 hours of percolating test results to do that | 22:59 |
| workthrick | jelmer: did you see my question from re: can't have unique root IDs without breaking existing checkouts, yesterday/yestermorning? | 23:00 |
| jelmer | workthrick: I think I replied to that | 23:01 |
| workthrick | might be, but I don't think I got any answer, it was probably after I disconnected | 23:01 |
| workthrick | if you don't mind repeating, I'd appreciate | 23:02 |
| jelmer | I thought it was a question on Launchpad? | 23:03 |
| workthrick | ah, no | 23:04 |
| workthrick | might I have a link then? | 23:04 |
| workthrick | <workthrick> jelmer: can't you make it happen only on new imports, and/or only if you opt-in with an option? | 23:04 |
| workthrick | that's what I meant | 23:04 |
| jelmer | workthrick: there's no way to tell is a new import - somebody else with bzr-git may have done an import of the git repository | 23:05 |
| fullermd | lifeless: CL == CAS latency, which has to do with activating a column. It's not exactly read access latency, but it's close enough that you can read it as a relative proxy. | 23:05 |
| lifeless | k | 23:05 |
| fullermd | (there are like a dozen different latency measures in DRAM, all of which give me a headache trying to understand) | 23:06 |
| lifeless | fullermd: do you happen to know if the i-2600 has rank limitations ? | 23:06 |
| lifeless | or do they not apply in ddr3 ? [all the docs I found so far talk ddr/ddr2] | 23:06 |
| fullermd | I think it just doesn't get talked about anymore; everybody handles dual-ranked DIMMS (16 chips, or 18 for ECC), and everything about that is in buffered territory. | 23:06 |
| fullermd | s/about/above/ | 23:07 |
| lifeless | fullermd: do consumer motherboards deal with buffered dimms ? | 23:08 |
| workthrick | jelmer: yes, but I can always opt into that, and even if that fails, I can always sync the two imports going through an intermediate git stage which is sure to interoperate. I'm much more concerned about the ability to interoperate with myself (and the ability to join multiple git checkoiuts into my project's repo) than potential somebody which might or might not exist. If I need to exchange patches with them, that's why I have a github branch in the fi | 23:08 |
| workthrick | rst place | 23:08 |
| fullermd | Nope. That's all Xeon/Opteron territory. | 23:08 |
| lifeless | ah | 23:09 |
| lifeless | maybe I should look at a mac pro | 23:09 |
| fullermd | (if they could, I'd have more than 8 gig. ZFS == hungry!) | 23:09 |
| workthrick | jelmer: in other words, I don't care whether bzr will consider new-style and old-style imports related as long as the history is equivalent and the mapping to/from git is stable within a checkout | 23:09 |
| workthrick | and as long as you can get a related checkout by specifying explitictly which style you want, of course | 23:10 |
| fullermd | I don't remember offhand if it's the board or the memory controller that's overridingly important for buffered vs non. | 23:10 |
| fullermd | If it's the board, you may be able to get a e.g. S1366 workstation board that will handle it. | 23:11 |
| jelmer | workthrick: in other words, you would want an option to specify a custom bzr<->git mapping to use | 23:11 |
| jelmer | workthrick: patches that make it easier to specifying the mapping are welcome, though I don't have any plans to work on this myself in the near future | 23:12 |
| workthrick | jelmer: rather something like --with-unique-roots or something, which'd tell bzr-git to create unique (but deterministic) root ID | 23:12 |
| jelmer | workthrick: that requires a new bzr<->git mapping | 23:12 |
| workthrick | jelmer: the problem is that the lack of that creates interoperability problems for me _right now_, because I wanted to go keep a local temporary checkout of upstream github projects until my patches get accepted, by having a bzr-git checkout outside of my project repo, joining a copy into the project repo, working on patches on the bzr-git checkouts, then merging them into my project for immediate use at the same time I send pull requests upstream, so t | 23:15 |
| workthrick | hat I can switch transparently over to the upstream once they merge my patches | 23:15 |
| workthrick | but I can't join more than one bzr-git checkout into my repo | 23:15 |
| workthrick | jelmer: right, but that mapping would be possible to create, right? Does git have something equivalent to root IDs, or something that can be deterministically transformed into one? | 23:16 |
| jelmer | workthrick: I'm sorry this is creating problems for you at the moment but it's a nontrivial problem to fix properly; you're welcome to register your own custom mapping that has more unique file ids | 23:16 |
| jelmer | workthrick: It's not just the root that's not unique, if two git repositories that are joined have a file named "README" this will also cause problems | 23:17 |
| workthrick | jelmer: sure, I understand it might not be trivial, I was just presenting the use case which I know creates problems (as opposed to wanting to merge with an independent old-style checkout, which is hypothetical for me at this time) | 23:17 |
| workthrick | jelmer: hmm, and is there something which somehow identifies a "repository" in a stable way? | 23:18 |
| jelmer | workthrick: supporting the joining of multiple git-imported trees into a single bzr branch is not on top of the todo list at the moment | 23:18 |
| workthrick | from what I understand, bzr in 2a does that explicitly at the time you commit the first revision, creating a unique ID which then needs to be repeated for the trees to be considered related, right? | 23:19 |
| jelmer | workthrick: there isn't really anything unique to identify a repository | 23:19 |
| workthrick | jelmer: is there some fastimport transformation I could apply mechanically to make it happen perhaps? | 23:19 |
| jelmer | workthrick: you can use fastimport itself, without involving bzr-git at all | 23:20 |
| workthrick | jelmer: hmm, so if I have two unrelated fastexports of a the same repo, which ordinarily would be considered unrelated in bzr, will git treat them as related if I dpush? | 23:21 |
| jelmer | workthrick: you can't dpush branches imported with bzr-fastimport | 23:21 |
| lifeless | fullermd: hah - http://www.asus.com/Motherboards/Intel_Socket_1155/Maximus_IV_Extreme/#specifications 'According to Intel® SPEC, the Max. 32GB memory capacity can be supported with DIMMs of 8GB (or above). ASUS will update QVL once the DIMMs are available on the market' | 23:21 |
| workthrick | jelmer: oh | 23:21 |
| workthrick | jelmer: so only branches bzr-git as marked as its own can be dpushed? | 23:22 |
| workthrick | *has | 23:22 |
| jave | I hve a branch which contains chonges I want to remove: http://bazaar.launchpad.net/~joakim-verona/inkscape/dbus-fixes/changes | 23:22 |
| jelmer | workthrick: it's not whether they're marked or not, it's that branches created by bzr-fastimport don't contain the same data (and the history has to be *exactly* the same) | 23:23 |
| workthrick | jelmer: even if no filtering is done on fastimport? WHat's lost in this case? | 23:24 |
| jave | the undesired change is the removal of a file. | 23:24 |
| jelmer | workthrick: how do you want to use dpush though, if the branches were joined with "bzr join" ? dpush would dpush the root branch | 23:24 |
| workthrick | jave: do you want to remove it from history, or just revert its effect? | 23:24 |
| jave | the problem is that the maintainers cant read the diff because the diff now is too large | 23:25 |
| fullermd | lifeless: Yah. 4Gb DRAM chips are somewhat beyond the "look, we can make this" stage, but aren't in mass prod yet. And we're probably 2 or 3 memory shrinks away from them really filtering into the client market. | 23:25 |
| workthrick | jelmer: nono, that's why I have a separate bzr-git clone outside of the repo; I then copy it inside and join, so that I can still merge *from* the bzr-git (but not to, so the work happens on bzr-git copy) | 23:25 |
| jave | workthrick: so, the shortest path to inclusion in trunk i guess | 23:25 |
| fullermd | lifeless: I was guessing 2014-5 the other day for when 8GB DIMMs get down to near $/gig parity. | 23:25 |
| workthrick | jave: I don't understand | 23:26 |
| jelmer | workthrick: filtering is possiblein theory, but would have the same effect of using bzr-git to do the clone | 23:26 |
| workthrick | jave: but the maintainer can always say bzr st -c $revno | 23:26 |
| jelmer | workthrick: it creates a branch with file ids that are based on the paths | 23:27 |
| workthrick | that will show them additions and removals without showing a full content diff | 23:27 |
| fullermd | (2Gb DRAM's were in real, though limited, production in like 2009, but it's only this year that 4GB DIMMs got down close to pricing parity) | 23:27 |
| workthrick | jelmer: ah, so bzr won't assign a root ID upon the first commit? | 23:27 |
| jave | workthrick: the burden seems to be on my shoulder if I want the patch accepted | 23:27 |
| workthrick | jave: I still don't understand what you want to do | 23:27 |
| jave | workthrick: http://bazaar.launchpad.net/~joakim-verona/inkscape/dbus-fixes/revision/10013#po/inkscape.pot | 23:28 |
| jelmer | workthrick: it still would - the branch would be exactly the same as if it were imported with bzr-git | 23:28 |
| jelmer | workthrick: even if it wouldn't, bzr dpush would rewrite the branch to have a non-unique root file id | 23:28 |
| jave | workthrick: po/inkscape.pot was removed there. Then I tried adding it back later but that didnt help | 23:28 |
| lifeless | fullermd: mmm, ugh. | 23:29 |
| workthrick | jelmer: xchat crashed, sorry | 23:29 |
| jelmer | <jelmer> workthrick: it still would - the branch would be exactly the same as if it were imported with bzr-git | 23:30 |
| jelmer | workthrick: even if it wouldn't, bzr dpush would rewrite the branch to have a non-unique root file id | 23:30 |
| workthrick | jelmer: okay, and would it be technically possible to register a mapping that synthesises IDs based on the first revision in the history? If so, I'd be satisfied with this measure of "identity", I don't really see much use in desperately trying to intermarry histories which differ on the first commit | 23:31 |
| lifeless | ahha | 23:32 |
| lifeless | F3-16000CL7Q-8GBFLS(XMP) | 23:32 |
| jelmer | workthrick: the root id isn't used to identify the tree in any way - it's just the file id of the root directory | 23:32 |
| workthrick | jelmer: so the ids would be, say, history[0].sha1 + path | 23:32 |
| workthrick | jelmer: I understand that | 23:33 |
| workthrick | but we're talking about a custom mapping which creates unique IDs while being stable amongst related trees | 23:33 |
| jelmer | workthrick: that would be possible to do for simple histories, not in all cases | 23:34 |
| workthrick | jelmer: oh, can you describe a case in which it'd fail? | 23:35 |
| jelmer | the very first left hand side ancestor doesn't have to be the same for all revisions in a revision graph | 23:35 |
| workthrick | I can't really see a situation in which the first parent would be different | 23:35 |
| fullermd | lifeless: *blink* That's a 4x set of 2GB's. | 23:36 |
| workthrick | jelmer: but wouldn't bzr then see them as unrelated? | 23:36 |
| maxb | jave: Is there still a problem? It looks like you put things right in 10022 ? | 23:36 |
| jelmer | workthrick: http://pastebin.ubuntu.com/619457/ | 23:36 |
| jelmer | workthrick: for D and E that revision is different than for C and F | 23:36 |
| jelmer | workthrick: for D and E that revision is different than for C, F and G | 23:36 |
| workthrick | jelmer: yes, but that's a situation in which you have two completely independent trees being merged, which won't arise unless the tree joins in another tree. I'd be happy to give up the ability to merge automatically git trees which join in other trees in exchange for being able to join in multiple trees myself | 23:39 |
| jave | maxb: heres the merge discussion: https://code.launchpad.net/~joakim-verona/inkscape/dbus-fixes/+merge/59877 | 23:39 |
| jelmer | workthrick: it doesn't have to involve a join - you can merge arbitrary trees together any time | 23:40 |
| workthrick | jelmer: unless I'm not seeing something and such a situation can arise in the course of normal single-tree history, I'm perfectly happy to work only on simple histories | 23:40 |
| workthrick | jelmer: sure, I know, a join is nothing else than an automated way to do a specific type of two-tree merge | 23:40 |
| jelmer | workthrick: so, in that case you can add a custom bzr plugin which registers a new bzr-git mapping that does what you want | 23:40 |
| workthrick | but it's a tradeoff I'm willing to take | 23:41 |
| workthrick | jelmer: mhm, would you mind outlining how that is done? | 23:41 |
| jelmer | workthrick: it wouldn't be something that's suitable for inclusion in bzr-git itself, because of the limitations mentioned | 23:41 |
| lifeless | fullermd: yes, bad QVL bad | 23:41 |
| jelmer | workthrick: sure | 23:41 |
| lifeless | fullermd: took me a bit to work that out | 23:41 |
| maxb | jave: Did you actually intend there to be any modifications to the pot file on your branch? Can we just throw it away and revert to trunk's version of it? | 23:41 |
| jelmer | workthrick: you would need to create a subclass of BzrGitMapping (see mapping.py in bzr-git) | 23:42 |
| jelmer | workthrick: and then register it | 23:42 |
| workthrick | jelmer: what about making it an default-off switch you have to specify explicitly to get that? The very reason I'm using bzr-git is because it allows me to play with github upstream trees without touching git, so I imagine I'm not the only person ever to have the problem | 23:42 |
| jave | maxb: yes if I ca revert to the trunk version that woulb be fantastic | 23:43 |
| workthrick | jelmer: ah, cool. And how do I get at the first revisions sha1? | 23:43 |
| jave | maxb: I have no idea why it got removed in the first place | 23:43 |
| maxb | jave: People seem to have given an answer to why in the merge proposal comments | 23:44 |
| workthrick | jelmer: so basically bzr clone --with-unique-ids git://foo.git? | 23:44 |
| maxb | jave: Anyway, I think "bzr revert -r ancestor:lp:inkscape po/inkscape.pot; bzr commit" should sort things out | 23:44 |
| jave | maxb: thanks! | 23:44 |
| jelmer | workthrick: it's not suitable for mainstream use because of the corner case mentioned, it's a nontrivial amount to support that too | 23:44 |
| jelmer | workthrick: adding options to bzr clone isn't possible from within bzr-git at the moment- it would need patching of bzr itself | 23:45 |
| workthrick | jelmer: even if it'd be documented to have that limitation and that it's intended to support a specific use-case you're supposed to understand? | 23:45 |
| workthrick | jelmer: oh | 23:45 |
| jave | maxb: well obviously I made an error. what I meant is that I cant figure out how I made that error. I dont recall doing "bzr clean> | 23:45 |
| jelmer | workthrick: it's too much effort to support that properly, I would rather work on fixing the more structural issues with file ids | 23:45 |
| workthrick | OK | 23:46 |
| workthrick | jelmer: and I'll be still able to push to github and interoperate within imports using that mapping afterwards? | 23:46 |
| jelmer | workthrick: you should be able to, in theory | 23:48 |
| jelmer | workthrick: this is all untreated territory so you might run into bugs | 23:48 |
| workthrick | that's what I'm after, otherwise I can just import the files without history and not bother pulling in the history | 23:48 |
| workthrick | jelmer: aha | 23:48 |
| workthrick | I'll take a stab at it tomorrow-ish then | 23:48 |
| jelmer | I'm happy to give advice and help fix the more structural bugs in bzr-git you might run into | 23:49 |
| workthrick | jelmer: one more thing, what does getting the first revision and its sha1 involve? | 23:49 |
| workthrick | do I use pure bzr APIs, or some bzr-git/dulwich specific ones | 23:50 |
| workthrick | ? | 23:50 |
| workthrick | jelmer: sure, thanks. That's one thing I've never had any reasons to complain about in your plugins :) | 23:50 |
| workthrick | and I sure ran into more bzr-svn bugs than I can count | 23:51 |
| jelmer | workthrick: you might have to patch bzr-git to allow it to do something like that | 23:51 |
| workthrick | jelmer: aha, I will bother you tomorrow then. Will you accept such patches as long as they're clean and don't change the default behaviour? | 23:51 |
| jelmer | workthrick: depends on the patch I guess; I don't mind e.g. passing along the revision id of the current revision, but not the revision of the first one in the ancestry (which would impact performance) | 23:52 |
| workthrick | jelmer: yes, I suspected it'd impact performance, but exposing an on-demand pathway to it would be kosher? | 23:53 |
| jave | maxb: the diff seems much better now. thanks again | 23:53 |
| jelmer | workthrick: again, really depends on the patch | 23:53 |
| workthrick | jelmer: also is there a mechanism bzr-git can use to mark trees it created with that mapping to recognise them later on? | 23:54 |
| jelmer | workthrick: the first bit of the revision id identifies the mapping | 23:54 |
| workthrick | aha, cool | 23:54 |
| jelmer | e.g. if you look at the revision id of standard bzr-git created revisions you'll find "git-v1:..." | 23:55 |
| jelmer | that name comes from the mapping subclass, you'd probably want to set 'prefix = "git-worthrick"' or something like that | 23:55 |
| workthrick | jelmer: hmm, thinking of relatively least bothersome way to integrate it into the UI, do you think creating a custom URL handler (something like uniquify:git://...) would be reasonable to do? | 23:56 |
| workthrick | and/or git+fileids:// | 23:57 |
| jelmer | workthrick: it should be possible to do something like that, but you'd need to patch bzr-git | 23:58 |
| workthrick | ok | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!