lifeless netdur I'm not sure wat you are saying ;)00:03
netdurI guessed so!00:06
=== Mario__ is now known as pygi
=== toytoy_ is now known as toytoy
nDuffwhoa -- 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
spivnDuff: hmm, I don't think we've seen that before.01:27
spivnDuff: You're on windows, IIRC?01:27
nDuffspiv, no; a bunch of other developers here are on win32, but I'm very much not.01:28
nDuffspiv, notably, I'm using bzrlib directly (and did the move using wt.move()), so there could well be a usage error.01:28
spivnDuff: drat; I was speculating that it might be a case-insensitive fs issue.01:28
spivAh, it might well be a usage error then.  I'm not overly familiar with those APIs.01:29
lifelessnDuff: reproducable?01:29
lifelessnDuff: what bzrlib version01:29
nDufflifeless, happens every run. 1.10rc101:30
lifelessnDuff: 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
nDufflifeless, 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
* nDuff looks for a pastebin01:32
lifelessare you able to try invoking bzr?01:32
nDufflifeless, 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
lifelessnDuff: or replace the wt.move call with system() ?01:34
nDufflifeless, 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
lifelessnDuff: oh, this is occuring when you do the commit?01:35
lifelessare you moving one file or many?01:35
lifelesstry using wt.rename_one01:35
lifelessmove is hmmm odd01:35
lifelessif that works its a bug in move and you have a workaround01:36
nDuffahh; this gives a much more useful exception01: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
lifelessits a commit issue then - can you get a backtrace for where its being raised from01:39
lifeless[probably a commit issue]01:40
lifelessuhm, can you add a call to wt._check() before your commit01:40
nDuffsure, doing that...01:40
nDuffthe _check() call is uneventful.01:41
lifelesswell that means that the dirstate thinks there is nothing wrong01:43
lifelessits either a bug in update_basis_by_delta01:44
lifelessa bug in the delta generation from commit01:44
lifelessis 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
nDuffthe only operation during that commit, correct.01:48
lifelessthe out of date is because the update failed01:48
lifelesscan you:01:48
lifelessbzr branch -r -2 . /tmp/foo01:49
lifelesscd /tmp/foo01:49
lifelessbzr mv whatever whatever [reproduce]01:49
lifelessbzr commit -m "make it blow up"01:49
nDuffdoesn't blow up from the command line.01:50
lifelessuncommit; revert01:51
lifelessimport bzrlib.workingtree; t = bzrlib.workingtree.WorkingTree.open('.') ...01:51
lifelesst.rename_one | move01:51
lifeless(see if that makes it reload)01:52
nDuffworks 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
lifelessthey shouldn't01:55
lifelessthat would be a bug too :P01:55
lifelesshow many commits are done in the tree?01:56
nDuff3 in total01:56
lifelessso 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
lifelessbzr is meant to be totally safe here, but I guess a bug is possible :P01:59
nDuffI'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
nDuffLet me take a little sillyness out of my commit routine...02:04
nDuffah hah!02:05
nDuffso -- 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
nDufftwo different data models -- one in-memory, one on-disk02:06
lifelessI'm smirking :)02:07
lifelessIt is a bug that you managed to get bzr to be unhappy02:07
lifelessif 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
nDufflifeless, heh -- turns out the rename/move call isn't actually necessary to get this result.02:30
lifelessremember that bzr has an inode abstraction02:34
ubottuLaunchpad bug 314251 in bzr "InconsistentDelta by recreating a known ID in a new location " [Undecided,New]02:35
lifelessnDuff: fun, thanks02:37
lifelessnDuff: do you need me to poke at this right now, or are you right?02:38
nDufflifeless, 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
lifelessnDuff: oh sure, its just latent-vs-actual02:40
lifelessI suspect a bug in add TH02:40
lifelessadd TH02:40
lifelessadd to be honest02:40
nDufflifeless, ...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
lifelessIf I can be nosy, what are you creating?02:42
nDufflifeless, a revision-controlled hierarchial datastore, backending into bzr for the SCM-ish workflow functionality.02:43
lifelessyou may find the brisbane core temporal hash table interesting02:43
nDuffhrm; looks like I might need to find a coworker with ACM membership to read up on that.02:46
lifelessheh this is something we've been working on02:46
lifelessthe bzrlib.chk_map module is the guts, and bzrlib.inventory.CHKInventory shows it being used to store inventories02:48
nDuffdoesn't seem accessible at the moment.02:48
lifelessnDuff: try again :P02:48
lifelessalso 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 fix02: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 lunch02:56
lifelesswofl_: they are good, native interop with svn, beta native interop with git and hg, a solid cvs convertor02:56
pooliewofl_: pretty good; we can import from all of them, and for all except cvs can either export to them, or treat them as foreign branches02:56
lifelesswofl_: also we support the fast-export streaming standard02:56
wofl_cool, how is the git and hg support coming?02:57
lifelesswell 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
lifelessits one way, we can import from cvs, but don't have a good answer for exporting to cvs03:00
lifelessyou could use tailor for that, which is a 3rd party generic tool03:01
wofl_for the export?03:03
lifelesstime for me to call it a day; 8 hours+ done04:51
poolienight lifeless04:51
vilahi all07:01
pooliehello vila07:32
pooliehappy new year07:32
igchi vila07:37
vilahappy new year bzrers :)07:38
* igc dinner - night all08:07
=== thekorn_ is now known as thekorn
=== asac_ is now known as asac
=== beaumonta is now known as abeaumont
garyvdmping vila11:17
vilagaryvdm: pong but lunch time here what's up ?11:21
garyvdmvila: I want to ask some questions about tests I'm writing for my no working tree bzr-upload branch. Later is ok11:23
vilagaryvdm: back12:24
garyvdmHi vila12:24
garyvdmI'm trying to write some tests for my no working tree branch. To be honest - I'm very inexperienced with writing tests.12:25
vilagaryvdm: ok, np, we all started there you know12:25
garyvdmSo I want to check I'm approaching things the right way,12:26
garyvdmI'm testing the intended workflow - not just upload from a branch with no working tree.12:26
garyvdmI.e. I'm pushing to the remote location, and then uploading from the remote location.12:27
garyvdmThis is also easier because I can just inherit from TestUploadMixin, and override do_full_upload and do_incremental_upload12:28
vilahmmm, I see your problem12:29
vilaI don't think you can do better right now, but the test framework (in the plugin) targets a more usual setup12:30
garyvdmNow there are some test which are not applicable: test_no_upload_when_changes, and test_no_upload_when_conflicts12:30
vilaIn fact you were the first to realized the WT wasn't needed12:30
vilagaryvdm: 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 TestNotApplicable12:32
vilaWe'll refactor later and having more examples will make that eaiser12:33
garyvdmOk - thats easy.12:33
vilaTry to review where the docs (string and user) may be misleading regarding the ambiguity about having a WT or not12:34
vilaRemember that we plan to add a better chmod bits support which *requires* a WT12:34
garyvdmOk - Last question: what bits would you intend on modifying with chmod?12:35
garyvdmThat would need to come from the wt?12:35
vilagaryvdm: hehe, good question for which I wait for feedback from unknown (to me) use cases12:35
vilaAIUI that's mainly g+w for some directories12:36
vilamaybe a+w in some cases...12:36
garyvdmSorry - whats a+w?12:36
garyvdmand g+w?12:36
vilawritable by group or writable by all12:36
vilaYou're on windows ?12:38
garyvdmRight now I'm on Ubuntu - But I am subjected to windows alot.12:38
garyvdmAnd I have clients using bzr-upload that are on windows12:39
vilaOk, I think the chmod bits are less relevant when the targeted *server* in on windows but I lack experience there to be sure12:39
garyvdmYes - chmod does not exist on windows.12:40
vilaThe use cases that were reported were for upload directories needing to world writable so that people can upload photos or pictures etc12:40
vilaI don't know how that's handled on a windows server12:40
garyvdmIt has a very different permissions structure, and no executable bit.12:40
LarstiQone thing I've seen happen12:40
LarstiQa file that needed +x set on the server, but development was done on windows and the bit never got set12:41
garyvdmThis is a plugin that allows you to set the +x bit on windows.12:41
vilaLarstiQ: ouch, I'm not sure we even have a way to force that on windows...12:41
vilagaryvdm: thks for the speed-light answer :)12:42
LarstiQgood :)12:42
=== beaumonta is now known as abeaumont
=== toytoy_ is now known as toytoy
tsdhHi.  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
beunotsdh, if I remember correctly, bzr checkout .13:16
LarstiQyes, bzr checkout13:16
LarstiQbut you need not have the working trees in the same location as the branches13:17
tsdhSounds good, I'd say.  And it seems to do something...13:17
tsdhOh, a progress bar appeared.  Thanks.13:17
=== Mario__ is now known as pygi
Ollie|trying to see the changes in a specific version so i do bzr st -r415:11
Ollie|but it just shows the current status as if the -r4 wasn't there15:11
Ollie|just wondering i have got the argument wrong15:11
beunoOllie|, bzr log -v -r415:11
Ollie|beuno: nice :)15:12
fullermdOllie|: 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
fullermdOllie|: Try "bzr stat -r3..4" or "bzr stat -c4"15:44
Ollie|fullermd: thanks15:46
salty-horsehi. can someone please rationalize the image dimensions on http://bazaar-vcs.org/Workflows ?15:53
=== Mario__ is now known as pygi
rexbronjames_w: I wrote a responce to your code review, have you had a chance to read it?16:42
james_wrexbron: I don't have a strong opinion which way round the profiles should be specified currently16:50
james_wthe 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 collisions16:51
rexbronjames_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 that16:57
james_w~/.bazaar/locations.conf etc.16:58
jelmerhi Mario (x2)17:07
=== Mario__ is now known as pygi
TorneI'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
Tornepossible complication: the branch in question was a loom17:14
Torneheads doesn't list it, only the two branches i've not broken. *tries --all*17:15
Torneaha, there it is17:15
Peng_Ehh, I don't know about the loom though.17:16
Peng_I don't know how they're stored.17:16
Tornei don't care if it breaks the loom nature of it as long as i get the changesets back17:16
Tornethe top patch on the loom didn't exist anywhere else so i need those deltas :)17:16
* Torne pulls it to see what happens17:17
Torneyup, that's recovered the revisions17:19
Torneit's lost the loom nature of it, but it has the revisions from each thread stacked on top of each other17:20
Torneso, 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
Torneheh, it's ok17:29
Tornei weas just curious :)17:29
Tornei have my code back; disk space is cheap :)17:31
TorneBye! :)17:31
=== bac is now known as bac_lunch
enigma42hm...I'm getting an error with the latest trunk of bzr-svn 0.517:43
enigma42bzr: ERROR: exceptions.ImportError: cannot import name ForeignRepository17:43
jelmerenigma42, you need bzr.dev to run bzr-svn 0.517:44
enigma42jelmer: Oh, OK. Due to the recent foreign repo stuff?17:44
enigma42So, that foreign repo stuff will be in bzr 1.11 when it comes out?17:45
enigma42jelmer: OK.17:47
enigma42jelmer: I have a couple of bugs for you, so I'll see if I can get them into the bug tracker today.17:47
jelmerenigma42, cool, thanks17:47
enigma42jelmer: I just want to test with the latest code to make sure they haven't been fixed already. :-)17:48
enigma42Are the bzrtools in "bzr.dev"? or somewhere else?17:49
enigma42nevermind. I think I just figured it out... http://bazaar-vcs.org/BzrTools17:50
Kobazhow would i list revisions that have not been pushed to a remote repo18:00
beunoKobaz, bzr missing18:00
Kinnisonbzr missing --mine-only <optional remote branch>18:00
=== bac_lunch is now known as bac
nDuffre 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
ubottuLaunchpad bug 314251 in bzr "InconsistentDelta by recreating a known ID in a new location " [High,Confirmed]18:27
Goundythere's no open source bzr web front-end ?18:41
Peng_Along with bzrweb and bzr-webserve.18:41
Goundyow ôO18:42
GoundyPeng_ 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
Goundythanks man18:42
GoundyPeng_ bazaar is so good man !19:21
GoundyI really like it !19:21
Peng_You shouldn't direct the credit to me, but yes, it is. :D19:22
GoundyPeng_ I can't stop saying that :/19:23
GoundyI told everybody how much I like bzr...19:23
dwthey there19:40
dwtI frequently see parts and info about subtree support in bzr19:40
dwtbut googling and searching the wiki doesn't seem to bring up any real documentation about that19:40
dwtcould 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/NestedTrees19:49
dwtthats why I didn't find anything with "subtree"19:49
dwtwhat is the eventual goal of this development?19:50
dwtWe use svn:externals extensively at work - and nested trees kinda sounds like it could be something like this19:50
dwt(even though svn:externals are pretty broken in and on itself)19:51
Kobazwhat's wrong with svn:externals ?19:59
dwtTo us it's hard to switch them between trunk / a branch/tag and specific revision20:04
=== bac is now known as bac_afk
Kobazah, yeah20:04
fdvuhn.. 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
jelmerfdv, yes20:17
jelmerfdv, that's not specific to bzr-svn btw20:17
headlessagnewjelmer: 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
fdvno, just providing context20:17
fdvthat's sad20:18
jelmerfdv, the changes end up as a pending merges so their history is still kept, just not part of the history of the current working tree20:18
fdvI got an error while updating, and my changes vanished20:18
jelmerfdv, what sort of error?20:19
jelmerheadlessagnew, when do you get that error?20:19
fdvjelmer: 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
headlessagnewjelmer: 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 %2F20:20
jelmerheadlessagnew, this is with the same repository?20:22
fdvI cleverly reverted, in the blissful belief that my changes were safe and sound in the history :p20:23
headlessagnewjelmer: yup, same thing if i do branching or checking out of trunk/branch/tags20:23
jelmerfdv, this is with 0.4.16?20:23
fdvuhm, no, 0.4.15dev020:25
fdvthe updates are so frequent it's hard to keep up :)20:25
headlessagnewjelmer: it fetches all the revision info, determines changes, and then on "copying revisions" it dies with the error.20:27
jelmerheadlessagnew, what I mean is, is this the same repository that you were working on last time?20:28
headlessagnewjelmer: 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
jelmerheadlessagnew, did you change this particular file at all?20:38
headlessagnewjelmer: I thought I hadn't, but yes, in fact I did.  And I made that change with bzr-svn.20:41
jelmerheadlessagnew, which version of bzr-svn ?20:43
headlessagnewjelmer: i made the change with 0.4.16, and on machine #2 i have tried with both 0.4.16 and 0.5rc120:43
headlessagnew(there was an indication in a bug tracker than a problem like this was fixed in 0.5)20:44
BUGabundowhat's up with bzr-beta-ppa team??21:33
igcmorning all21:56
EmmanuelI 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
EmmanuelAny idea what goes wrong22:09
nDuffEmmanuel, does the break-lock command help?22:10
nDuffEmmanuel, 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
EmmanuelnDuff , let me try22:11
EmmanuelIt is actually my initial push22:12
Emmanuelseems a little bit better22:13
BUGabundowhat's up with bzr-beta-ppa team??22:17
Emmanuelit made it work thx, thx guys22:40
nDuffglad to hear22:40
pooliehello all23: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
ubottuLaunchpad bug 314251 in bzr "InconsistentDelta by recreating a known ID in a new location " [High,Confirmed]23:10
nDuffpoolie, howdy23:10
pooliehello nDuff23:10
lifelessnDuff: yes23:44
nDufflifeless, 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
lifelessnDuff: it does23:51
nDuffodd, then.23:51
lifelessnDuff: 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!