| lifeless | netdur I'm not sure wat you are saying ;) | 00:03 |
|---|---|---|
| netdur | I guessed so! | 00:06 |
| netdur | :( | 00:06 |
| netdur | sorry | 00:07 |
| === Mario__ is now known as pygi | ||
| === toytoy_ is now known as toytoy | ||
| nDuff | whoa -- InconsistentDelta: An inconsistent delta was supplied involving '<PATH>', '<ID>' \n reason: The entry was considered a rename, but the source path is marked as absent. | 01:24 |
| nDuff | ...where the PATH and ID refer to a file which was under a directory I was trying to rename, but not anything that a rename should have been issued on standing alone. | 01:25 |
| spiv | nDuff: hmm, I don't think we've seen that before. | 01:27 |
| spiv | nDuff: You're on windows, IIRC? | 01:27 |
| nDuff | spiv, no; a bunch of other developers here are on win32, but I'm very much not. | 01:28 |
| nDuff | spiv, notably, I'm using bzrlib directly (and did the move using wt.move()), so there could well be a usage error. | 01:28 |
| spiv | nDuff: drat; I was speculating that it might be a case-insensitive fs issue. | 01:28 |
| spiv | Ah, it might well be a usage error then. I'm not overly familiar with those APIs. | 01:29 |
| lifeless | nDuff: reproducable? | 01:29 |
| lifeless | nDuff: what bzrlib version | 01:29 |
| nDuff | lifeless, happens every run. 1.10rc1 | 01:30 |
| lifeless | nDuff: if you create a fresh checkout? | 01:30 |
| lifeless | (there was a bug quite a while back with dirstate, it is possible but unlikely that you are suffering from the confusion that bug could introduce) | 01:31 |
| nDuff | lifeless, this is during the commit process (from my test suite, so a new branch is made every invocation); can't check out what isn't committed yet. | 01:31 |
| lifeless | ok | 01:32 |
| * nDuff looks for a pastebin | 01:32 | |
| lifeless | are you able to try invoking bzr? | 01:32 |
| nDuff | lifeless, I'll need to comment out the test suite's tearDown bits that delete the tree on each run to inspect manually; will do... | 01:33 |
| lifeless | nDuff: or replace the wt.move call with system() ? | 01:34 |
| nDuff | lifeless, I'm quite sure that the mv is happening on the underlying filesystem when I call wt.move() -- otherwise a check I'm doing before the commit would fail. | 01:34 |
| lifeless | nDuff: oh, this is occuring when you do the commit? | 01:35 |
| nDuff | yes. | 01:35 |
| lifeless | are you moving one file or many? | 01:35 |
| nDuff | one | 01:35 |
| lifeless | try using wt.rename_one | 01:35 |
| lifeless | move is hmmm odd | 01:35 |
| lifeless | if that works its a bug in move and you have a workaround | 01:36 |
| nDuff | ahh; this gives a much more useful exception | 01:37 |
| nDuff | ...blerg, the useful exception was just because usage between move and rename_one differs; fixing that, it's back to the same issue. | 01:39 |
| lifeless | ok | 01:39 |
| lifeless | its a commit issue then - can you get a backtrace for where its being raised from | 01:39 |
| lifeless | [probably a commit issue] | 01:40 |
| lifeless | uhm, can you add a call to wt._check() before your commit | 01:40 |
| nDuff | http://pastebin.ca/1300603 | 01:40 |
| nDuff | sure, doing that... | 01:40 |
| nDuff | the _check() call is uneventful. | 01:41 |
| lifeless | well that means that the dirstate thinks there is nothing wrong | 01:43 |
| lifeless | so... | 01:44 |
| lifeless | its either a bug in update_basis_by_delta | 01:44 |
| lifeless | or | 01:44 |
| lifeless | a bug in the delta generation from commit | 01:44 |
| lifeless | is this the only operation made to the tree? | 01:47 |
| nDuff | ...going into the directory (after disabling cleanup), a "bzr status" showed the working tree out-of-date, but "bzr update" completed successfully. | 01:48 |
| nDuff | the only operation during that commit, correct. | 01:48 |
| lifeless | the out of date is because the update failed | 01:48 |
| lifeless | can you: | 01:48 |
| lifeless | bzr branch -r -2 . /tmp/foo | 01:49 |
| lifeless | cd /tmp/foo | 01:49 |
| lifeless | bzr mv whatever whatever [reproduce] | 01:49 |
| lifeless | bzr commit -m "make it blow up" | 01:49 |
| nDuff | doesn't blow up from the command line. | 01:50 |
| lifeless | ok | 01:51 |
| lifeless | uncommit; revert | 01:51 |
| lifeless | python | 01:51 |
| lifeless | import bzrlib.workingtree; t = bzrlib.workingtree.WorkingTree.open('.') ... | 01:51 |
| lifeless | t.lock_write() | 01:51 |
| lifeless | t.rename_one | move | 01:51 |
| lifeless | commit | 01:51 |
| lifeless | (see if that makes it reload) | 01:52 |
| nDuff | works fine that way too. Could multiple WorkingTree instances made against the same directory during the course of operation interfere with each other in some way? | 01:54 |
| lifeless | they shouldn't | 01:55 |
| lifeless | that would be a bug too :P | 01:55 |
| lifeless | how many commits are done in the tree? | 01:56 |
| nDuff | 3 in total | 01:56 |
| lifeless | so its plausible that you have t1, do a commit, make a t2, do a commit, then use t1 to do a third commit ? | 01:57 |
| lifeless | bzr is meant to be totally safe here, but I guess a bug is possible :P | 01:59 |
| nDuff | I've reworked that logic a few times, and while there *is* a case where I can get a different kind of breakage, it's pretty clear that old wt objects are being thrown away. | 02:04 |
| nDuff | ...oh. | 02:04 |
| nDuff | Let me take a little sillyness out of my commit routine... | 02:04 |
| nDuff | ah hah! | 02:05 |
| nDuff | so -- this being an early 0.0.x version, I had some extra paranoia in the commit routine, where I completely removed and recreated the tree just before commit. | 02:06 |
| lifeless | really | 02:06 |
| nDuff | two different data models -- one in-memory, one on-disk | 02:06 |
| lifeless | I'm smirking :) | 02:07 |
| lifeless | It is a bug that you managed to get bzr to be unhappy | 02:07 |
| lifeless | if you wanted to file a script to trigger it, I'd be delighted to look at fixing it. | 02:08 |
| nDuff | *nod*; I'll see about doing that. | 02:08 |
| nDuff | lifeless, heh -- turns out the rename/move call isn't actually necessary to get this result. | 02:30 |
| lifeless | :> | 02:33 |
| lifeless | remember that bzr has an inode abstraction | 02:34 |
| nDuff | https://bugs.launchpad.net/bzr/+bug/314251 | 02:35 |
| ubottu | Launchpad bug 314251 in bzr "InconsistentDelta by recreating a known ID in a new location " [Undecided,New] | 02:35 |
| lifeless | nDuff: fun, thanks | 02:37 |
| lifeless | nDuff: do you need me to poke at this right now, or are you right? | 02:38 |
| nDuff | lifeless, a fix would be convenient (inasmuch as I could keep leaning on the same crutch for not getting consistency of my on-disk and in-memory models right), but the Right Thing is to squash any such bugs anyhow. :) | 02:39 |
| lifeless | nDuff: oh sure, its just latent-vs-actual | 02:40 |
| lifeless | I suspect a bug in add TH | 02:40 |
| lifeless | add TH | 02:40 |
| lifeless | bah | 02:40 |
| lifeless | add to be honest | 02:40 |
| nDuff | lifeless, ...taking the crutch out will make a huge difference in performance anyhow; this is just the impetus I needed to actually *do* it. | 02:41 |
| nDuff | ...so no hurry on my account. | 02:42 |
| lifeless | If I can be nosy, what are you creating? | 02:42 |
| nDuff | lifeless, a revision-controlled hierarchial datastore, backending into bzr for the SCM-ish workflow functionality. | 02:43 |
| lifeless | interesting | 02:43 |
| lifeless | you may find the brisbane core temporal hash table interesting | 02:43 |
| nDuff | hrm; looks like I might need to find a coworker with ACM membership to read up on that. | 02:46 |
| lifeless | heh this is something we've been working on | 02:46 |
| lifeless | http://bazaar.launchpad.net/%7Ebzr/bzr/brisbane-core/ | 02:47 |
| lifeless | the bzrlib.chk_map module is the guts, and bzrlib.inventory.CHKInventory shows it being used to store inventories | 02:48 |
| nDuff | doesn't seem accessible at the moment. | 02:48 |
| lifeless | nDuff: try again :P | 02:48 |
| lifeless | also its a bzr branch, you can just pull from there which won'y hit the web ui, which frankly, is suffering from the very things brisbane-core is aiming to fix | 02:49 |
| === Guest6865 is now known as wofl_ | ||
| wofl_ | hey, i was wondering about interoperability, i am currently looking for hopefully just one version control system for me, which will allow me to connect with others using git, mg, cvs and svn, as transpatent as possible. how are bzr's import and export capabilities? | 02:56 |
| * igc lunch | 02:56 | |
| lifeless | wofl_: they are good, native interop with svn, beta native interop with git and hg, a solid cvs convertor | 02:56 |
| poolie | wofl_: pretty good; we can import from all of them, and for all except cvs can either export to them, or treat them as foreign branches | 02:56 |
| lifeless | wofl_: also we support the fast-export streaming standard | 02:56 |
| poolie | jinx | 02:56 |
| wofl_ | cool, how is the git and hg support coming? | 02:57 |
| lifeless | well good, they are beta :) | 02:58 |
| wofl_ | and does the cvs converter mean i have a local cvs branch where i sync over and then commit from there? | 02:59 |
| lifeless | its one way, we can import from cvs, but don't have a good answer for exporting to cvs | 03:00 |
| lifeless | you could use tailor for that, which is a 3rd party generic tool | 03:01 |
| wofl_ | for the export? | 03:03 |
| lifeless | yes | 03:05 |
| lifeless | time for me to call it a day; 8 hours+ done | 04:51 |
| poolie | night lifeless | 04:51 |
| vila | hi all | 07:01 |
| poolie | hello vila | 07:32 |
| poolie | happy new year | 07:32 |
| igc | hi vila | 07:37 |
| vila | happy new year bzrers :) | 07:38 |
| * igc dinner - night all | 08:07 | |
| === thekorn_ is now known as thekorn | ||
| === asac_ is now known as asac | ||
| === beaumonta is now known as abeaumont | ||
| garyvdm | ping vila | 11:17 |
| vila | garyvdm: pong but lunch time here what's up ? | 11:21 |
| garyvdm | vila: I want to ask some questions about tests I'm writing for my no working tree bzr-upload branch. Later is ok | 11:23 |
| vila | garyvdm: back | 12:24 |
| garyvdm | Hi vila | 12:24 |
| garyvdm | I'm trying to write some tests for my no working tree branch. To be honest - I'm very inexperienced with writing tests. | 12:25 |
| vila | garyvdm: ok, np, we all started there you know | 12:25 |
| garyvdm | So I want to check I'm approaching things the right way, | 12:26 |
| garyvdm | I'm testing the intended workflow - not just upload from a branch with no working tree. | 12:26 |
| garyvdm | I.e. I'm pushing to the remote location, and then uploading from the remote location. | 12:27 |
| garyvdm | This is also easier because I can just inherit from TestUploadMixin, and override do_full_upload and do_incremental_upload | 12:28 |
| vila | hmmm, I see your problem | 12:29 |
| vila | I don't think you can do better right now, but the test framework (in the plugin) targets a more usual setup | 12:30 |
| garyvdm | Now there are some test which are not applicable: test_no_upload_when_changes, and test_no_upload_when_conflicts | 12:30 |
| vila | In fact you were the first to realized the WT wasn't needed | 12:30 |
| vila | garyvdm: I think the tests need to be refactored anyway, so don't spend too much time on that part, just override the tests you don't want to be applied with custom versions raising TestNotApplicable | 12:32 |
| vila | We'll refactor later and having more examples will make that eaiser | 12:33 |
| garyvdm | Ok - thats easy. | 12:33 |
| vila | Try to review where the docs (string and user) may be misleading regarding the ambiguity about having a WT or not | 12:34 |
| vila | Remember that we plan to add a better chmod bits support which *requires* a WT | 12:34 |
| garyvdm | Ok - Last question: what bits would you intend on modifying with chmod? | 12:35 |
| garyvdm | That would need to come from the wt? | 12:35 |
| vila | garyvdm: hehe, good question for which I wait for feedback from unknown (to me) use cases | 12:35 |
| vila | AIUI that's mainly g+w for some directories | 12:36 |
| vila | maybe a+w in some cases... | 12:36 |
| garyvdm | Sorry - whats a+w? | 12:36 |
| garyvdm | and g+w? | 12:36 |
| vila | writable by group or writable by all | 12:36 |
| garyvdm | Ok | 12:37 |
| vila | You're on windows ? | 12:38 |
| garyvdm | Right now I'm on Ubuntu - But I am subjected to windows alot. | 12:38 |
| garyvdm | And I have clients using bzr-upload that are on windows | 12:39 |
| vila | Ok, I think the chmod bits are less relevant when the targeted *server* in on windows but I lack experience there to be sure | 12:39 |
| garyvdm | Yes - chmod does not exist on windows. | 12:40 |
| vila | The use cases that were reported were for upload directories needing to world writable so that people can upload photos or pictures etc | 12:40 |
| vila | I don't know how that's handled on a windows server | 12:40 |
| garyvdm | It has a very different permissions structure, and no executable bit. | 12:40 |
| LarstiQ | one thing I've seen happen | 12:40 |
| LarstiQ | a file that needed +x set on the server, but development was done on windows and the bit never got set | 12:41 |
| garyvdm | This is a plugin that allows you to set the +x bit on windows. | 12:41 |
| vila | LarstiQ: ouch, I'm not sure we even have a way to force that on windows... | 12:41 |
| vila | garyvdm: thks for the speed-light answer :) | 12:42 |
| LarstiQ | good :) | 12:42 |
| garyvdm | https://launchpad.net/bzr-x-bit | 12:44 |
| === beaumonta is now known as abeaumont | ||
| === toytoy_ is now known as toytoy | ||
| tsdh | Hi. I downloaded a shared repository as tar.gz and now I have project/{branches,tags/trunk}/. But those directories are empty except the .bzr directories. How do I populate them out of the metadata in .bzr now? | 13:16 |
| beuno | tsdh, if I remember correctly, bzr checkout . | 13:16 |
| LarstiQ | yes, bzr checkout | 13:16 |
| LarstiQ | but you need not have the working trees in the same location as the branches | 13:17 |
| tsdh | Sounds good, I'd say. And it seems to do something... | 13:17 |
| tsdh | Oh, a progress bar appeared. Thanks. | 13:17 |
| === Mario__ is now known as pygi | ||
| Ollie| | hey | 15:10 |
| Ollie| | trying to see the changes in a specific version so i do bzr st -r4 | 15:11 |
| Ollie| | but it just shows the current status as if the -r4 wasn't there | 15:11 |
| Ollie| | just wondering i have got the argument wrong | 15:11 |
| beuno | Ollie|, bzr log -v -r4 | 15:11 |
| Ollie| | beuno: nice :) | 15:12 |
| fullermd | Ollie|: stat compares two things. With -r4 you're only giving it one, so it assumes the other (compares r4 against your working tree). | 15:44 |
| fullermd | Ollie|: Try "bzr stat -r3..4" or "bzr stat -c4" | 15:44 |
| Ollie| | fullermd: thanks | 15:46 |
| salty-horse | hi. can someone please rationalize the image dimensions on http://bazaar-vcs.org/Workflows ? | 15:53 |
| === Mario__ is now known as pygi | ||
| rexbron | james_w: I wrote a responce to your code review, have you had a chance to read it? | 16:42 |
| james_w | rexbron: I don't have a strong opinion which way round the profiles should be specified currently | 16:50 |
| james_w | the one other consideration that just popped in to my head is that it should probably migrate to using bzr's config files, in which case having a single header for all profiles would be less likely to cause collisions | 16:51 |
| rexbron | james_w: that would be something to investigate further. I do not know what exactly you mean by use bzr configfiles, as I would think it would be better to have plugin seperate from that | 16:57 |
| james_w | ~/.bazaar/locations.conf etc. | 16:58 |
| jelmer | hi Mario (x2) | 17:07 |
| === Mario__ is now known as pygi | ||
| Torne | I've deleted a branch i didn't mean to, in a shared repository. Is there any way to recover the committed revisions from taht branch? presumably they are still there :) | 17:10 |
| Peng_ | Torne: You could use bzrtools's "bzr heads" command. | 17:13 |
| Peng_ | Torne: Then, um, "bzr init", and "bzr pull . -r revid:...". | 17:13 |
| * Torne tries that :) | 17:14 | |
| Torne | possible complication: the branch in question was a loom | 17:14 |
| Torne | heads doesn't list it, only the two branches i've not broken. *tries --all* | 17:15 |
| Torne | aha, there it is | 17:15 |
| Peng_ | Ehh, I don't know about the loom though. | 17:16 |
| Peng_ | I don't know how they're stored. | 17:16 |
| Torne | i don't care if it breaks the loom nature of it as long as i get the changesets back | 17:16 |
| Torne | the top patch on the loom didn't exist anywhere else so i need those deltas :) | 17:16 |
| * Torne pulls it to see what happens | 17:17 | |
| Torne | yup, that's recovered the revisions | 17:19 |
| Peng_ | Cool. | 17:20 |
| Torne | it's lost the loom nature of it, but it has the revisions from each thread stacked on top of each other | 17:20 |
| Torne | thanks! | 17:20 |
| Torne | so, hm. a related question: if you have branches in a shared repository, is there actually a way to delete a branch that *will* throw away all the data for its revisions? :) | 17:26 |
| Peng_ | Not really. | 17:28 |
| Peng_ | I mean, you could create a new repo, pull everything but those revisions into it, and then switch them out... | 17:29 |
| Peng_ | I don't know of any better ways. | 17:29 |
| Peng_ | IIRC there *was* a plugin to delete revisions, but I don't know its status. | 17:29 |
| Torne | heh, it's ok | 17:29 |
| Torne | i weas just curious :) | 17:29 |
| Torne | i have my code back; disk space is cheap :) | 17:31 |
| Torne | Bye! :) | 17:31 |
| === bac is now known as bac_lunch | ||
| enigma42 | hm...I'm getting an error with the latest trunk of bzr-svn 0.5 | 17:43 |
| enigma42 | bzr: ERROR: exceptions.ImportError: cannot import name ForeignRepository | 17:43 |
| jelmer | enigma42, you need bzr.dev to run bzr-svn 0.5 | 17:44 |
| enigma42 | jelmer: Oh, OK. Due to the recent foreign repo stuff? | 17:44 |
| jelmer | yeah | 17:44 |
| enigma42 | So, that foreign repo stuff will be in bzr 1.11 when it comes out? | 17:45 |
| jelmer | yep | 17:47 |
| enigma42 | jelmer: OK. | 17:47 |
| enigma42 | jelmer: I have a couple of bugs for you, so I'll see if I can get them into the bug tracker today. | 17:47 |
| jelmer | enigma42, cool, thanks | 17:47 |
| enigma42 | jelmer: I just want to test with the latest code to make sure they haven't been fixed already. :-) | 17:48 |
| enigma42 | Are the bzrtools in "bzr.dev"? or somewhere else? | 17:49 |
| enigma42 | nevermind. I think I just figured it out... http://bazaar-vcs.org/BzrTools | 17:50 |
| Kobaz | how would i list revisions that have not been pushed to a remote repo | 18:00 |
| beuno | Kobaz, bzr missing | 18:00 |
| Kinnison | bzr missing --mine-only <optional remote branch> | 18:00 |
| Kobaz | k | 18:04 |
| Kobaz | nifty | 18:14 |
| === bac_lunch is now known as bac | ||
| nDuff | re https://bugs.launchpad.net/bzr/+bug/314251 -- if I'm understanding correctly, when we re-add with the same ID at a new location, we need to set the type of the old ID to 'r' if it had been 'a'. Correct? | 18:27 |
| ubottu | Launchpad bug 314251 in bzr "InconsistentDelta by recreating a known ID in a new location " [High,Confirmed] | 18:27 |
| Goundy | hi | 18:41 |
| Goundy | there's no open source bzr web front-end ? | 18:41 |
| Peng_ | Loggerhead? | 18:41 |
| Peng_ | Along with bzrweb and bzr-webserve. | 18:41 |
| Goundy | ow ôO | 18:42 |
| Goundy | Peng_ man I really sux.... I tried to find out something using google but all I get is links to messages to mailing lists... | 18:42 |
| Goundy | thanks man | 18:42 |
| Peng_ | :) | 18:44 |
| Goundy | Peng_ bazaar is so good man ! | 19:21 |
| Goundy | I really like it ! | 19:21 |
| Peng_ | You shouldn't direct the credit to me, but yes, it is. :D | 19:22 |
| Goundy | Peng_ I can't stop saying that :/ | 19:23 |
| Goundy | I told everybody how much I like bzr... | 19:23 |
| dwt | hey there | 19:40 |
| dwt | I frequently see parts and info about subtree support in bzr | 19:40 |
| dwt | but googling and searching the wiki doesn't seem to bring up any real documentation about that | 19:40 |
| dwt | could you point me to a site? | 19:40 |
| Peng_ | dwt: Try searching for "nested trees". It's been experimental for ages; not much has been happening. | 19:49 |
| Peng_ | dwt: Here's one page: http://bazaar-vcs.org/NestedTrees | 19:49 |
| dwt | ahhh | 19:49 |
| dwt | thats why I didn't find anything with "subtree" | 19:49 |
| dwt | what is the eventual goal of this development? | 19:50 |
| dwt | We use svn:externals extensively at work - and nested trees kinda sounds like it could be something like this | 19:50 |
| dwt | (even though svn:externals are pretty broken in and on itself) | 19:51 |
| Kobaz | what's wrong with svn:externals ? | 19:59 |
| dwt | To us it's hard to switch them between trunk / a branch/tag and specific revision | 20:04 |
| === bac is now known as bac_afk | ||
| Kobaz | ah, yeah | 20:04 |
| fdv | uhn.. when binding / updating (bzr-svn), local changes made while unbound will be "extracted" and become a diff. Are they then actually removed from the history as well? | 20:17 |
| jelmer | fdv, yes | 20:17 |
| jelmer | fdv, that's not specific to bzr-svn btw | 20:17 |
| headlessagnew | jelmer: A couple days ago you helped me out with bzr-svn, and downgrading to 0.4.x worked on that machine. On another OSX machine I keep getting "setup.py is already versioned" where setup.py is a file in the repository. This happens on OSX, SVN 1.5.5, with both 0.4 and 0.5 branches of bzr-svn, on both case sensitive and case insensitive filesystems. Any ideas? | 20:17 |
| fdv | no, just providing context | 20:17 |
| fdv | that's sad | 20:18 |
| jelmer | fdv, the changes end up as a pending merges so their history is still kept, just not part of the history of the current working tree | 20:18 |
| fdv | I got an error while updating, and my changes vanished | 20:18 |
| jelmer | fdv, what sort of error? | 20:19 |
| jelmer | headlessagnew, when do you get that error? | 20:19 |
| fdv | jelmer: bzr: ERROR: No such file: ('161254@6226825f-cf0a-0410-9073-f4040cba89582...', 'svn-v3-single1-dHJ1bmsvbWFpbg..:6226825f-cf0a-0410-9073-f4040cba8958:trunk%2Fmain:161254') | 20:20 |
| headlessagnew | jelmer: during a branch or checkout into an init'd repo with --rich-root-pack. It downloads (I believe) the entire history, then I'm nto sure where it dies because the output gets cleared. (Is there a swithc ot preseve output?) | 20:20 |
| fdv | ... being an existing path, with / replaced with %2F | 20:20 |
| jelmer | headlessagnew, this is with the same repository? | 20:22 |
| fdv | I cleverly reverted, in the blissful belief that my changes were safe and sound in the history :p | 20:23 |
| headlessagnew | jelmer: yup, same thing if i do branching or checking out of trunk/branch/tags | 20:23 |
| jelmer | fdv, this is with 0.4.16? | 20:23 |
| fdv | uhm, no, 0.4.15dev0 | 20:25 |
| fdv | the updates are so frequent it's hard to keep up :) | 20:25 |
| headlessagnew | jelmer: it fetches all the revision info, determines changes, and then on "copying revisions" it dies with the error. | 20:27 |
| jelmer | headlessagnew, what I mean is, is this the same repository that you were working on last time? | 20:28 |
| headlessagnew | jelmer: Yes, it is, but a different OSX machine. I have made changes to the repo via bzr-svn, but only commits -- no renames or moves. Additionally, I haven't made any new directories (branches or otherwise) since then, with either svn or bzr-svn. | 20:29 |
| jelmer | headlessagnew, did you change this particular file at all? | 20:38 |
| headlessagnew | jelmer: I thought I hadn't, but yes, in fact I did. And I made that change with bzr-svn. | 20:41 |
| jelmer | headlessagnew, which version of bzr-svn ? | 20:43 |
| headlessagnew | jelmer: i made the change with 0.4.16, and on machine #2 i have tried with both 0.4.16 and 0.5rc1 | 20:43 |
| headlessagnew | (there was an indication in a bug tracker than a problem like this was fixed in 0.5) | 20:44 |
| BUGabundo | hi | 21:33 |
| BUGabundo | what's up with bzr-beta-ppa team?? | 21:33 |
| igc | morning all | 21:56 |
| Emmanuel | Hi | 22:08 |
| Emmanuel | I am starting using bazaar and i have a pb ( i am using it on Vista and ver1.10 ). I get the following error message : "bzr: ERROR: Could not acquire lock" | 22:09 |
| Emmanuel | Any idea what goes wrong | 22:09 |
| nDuff | Emmanuel, does the break-lock command help? | 22:10 |
| nDuff | Emmanuel, typically that kind of issue means some previous command failed while holding the lock -- well, that or there's someone else doing something to the tree concurrently so you need to keep your hands off it. :) | 22:11 |
| Emmanuel | nDuff , let me try | 22:11 |
| Emmanuel | It is actually my initial push | 22:12 |
| Emmanuel | seems a little bit better | 22:13 |
| BUGabundo | what's up with bzr-beta-ppa team?? | 22:17 |
| Emmanuel | it made it work thx, thx guys | 22:40 |
| nDuff | glad to hear | 22:40 |
| poolie | hello all | 23:09 |
| nDuff | ...hrm; looks like the dirstate fails validation just before the commit failure in https://bugs.launchpad.net/bzr/+bug/314251. Does that make the dirstate getting into a bad state "the real bug" and the commit failure expected under the circumstances (thus, NOTABUG)? | 23:10 |
| ubottu | Launchpad bug 314251 in bzr "InconsistentDelta by recreating a known ID in a new location " [High,Confirmed] | 23:10 |
| nDuff | poolie, howdy | 23:10 |
| poolie | hello nDuff | 23:10 |
| lifeless | nDuff: yes | 23:44 |
| nDuff | lifeless, I'm curious, btw, that the wt._check() calls we put in when you were walking me through diagnosing this didn't catch the prior issue then; does wt._check() not check the dirstate? | 23:48 |
| lifeless | nDuff: it does | 23:51 |
| nDuff | odd, then. | 23:51 |
| lifeless | nDuff: WT4's self._validate, called by check, calls self._dirstate.validate() | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!