[00:03] jam: oh, also - the new ACF exception is harder for people to match on [00:03] jam: how do you feel about: [00:03] putting the string AbsentContentFactory in the string, [00:03] changing the exception to BzrError (or something like that, that doesn't spew a backtrace) [00:04] having it ask for a bug to be filed, with ~/.bzr.log's contents for that command [00:05] emmajane: hi, are you around? [00:09] mwhudson: bug 406898 [00:09] Launchpad bug 406898 in bzr "rocketfuel-setup (Launchpad) SHA1KnitCorrupt error" [Undecided,New] https://launchpad.net/bugs/406898 [00:09] lifeless: yeah, don't really know what's going on there [00:10] lifeless: it's probably a bzr-git bug? [00:10] (it's also intermittent, which is really strange) [00:10] not sure at all [00:10] or maybe it's not intermittent, but only happens over http or something [00:12] is the branch in 2a format? [01:04] poolie: good morning. [01:04] hullo spivvo [01:32] jam: i have comments on the lock-warning branch, please don't merge it yet [02:25] Ugh, the bazaar@ moderation queue has gotten huge. [02:37] spiv, oh probably, i haven't done it for a while and not many other people do [02:38] and i think the spam filteringthere is poor [02:39] Yeah. [02:49] lifeless: borrow your cvs knowledge very briefly? [02:49] sure [02:49] lifeless: https://pastebin.canonical.com/20636/ <- a chunk of rlog [02:49] lifeless: the date for 1.20 seems a little bong, correct? [02:50] yes [02:50] client had the date wrong [02:50] rule 1 of distributed systems, you can't trust anyones dates except your own [02:50] unless it's just a coincidence, i think this is confusing cscvs [02:50] (very hypothetical as of yet) [02:50] cscvs has a huge chunk of code to deal with this - it generates a DAG of the versions [02:51] then walks that DAG, in parallel for all files, for each branch [02:51] oh [02:51] theres a 'fun' test case in there [02:51] for the case of two files [02:52] with revs 1.1 @ time A, 1.2 @ time B in file F [02:52] and revs 1.1 @ time B, 1.2 @ time A, in file G [02:52] with the same commit messages [02:53] lifeless: the CVS/Catalog thats getting generated in this case has revision 1.20 as the only 'add' for this file [02:53] [you need to turn this into 3 commits - A 1.1; A1.2,B1.1; B1.2 [02:53] mwhudson: I think you're pulling on the right thread [02:54] this is one of the fundamental issues with CVS though; its not pretty [02:54] (I have actually seen that test case in the wild. Debugging that weirdness was Not Fun) [02:55] the only 'mainline' add, rather [02:57] its definitely wrong [02:58] so the /intent/ is that date is a hint but the DAG wins [02:58] ok [02:58] we start with N parallel DAGS, one per file [02:58] we collect across the DAGS by commit message [02:58] within that, cycles are broken - such as that vicious case above [02:59] finally, we walk in DAG,date order [02:59] so that if two commits on different files have no ordering to each other, date order wins [02:59] thats the intent. the reality - I think you've found damage :) [02:59] i think there are probably two bugs here [03:00] * lifeless is shocked [03:00] one is this case (it's from sane-backends) [03:00] the other, and this is rather more common, is that there seems to be a problem updating the catalog when a merge creates a file [03:06] mwhudson: I'm lunching/prepping LCA submission before the deadline [03:07] mwhudson: which is in 1 hour IIRC. So after that hassle me more :P [03:07] lifeless: cool, thanks for the thoughts so far [03:07] * mwhudson is off for a haircut soon in any case [03:17] lifeless: (in a non-pipeline, shelve would be as it is, in a pipeline it would add pipes?) All branches are single-pipe pipelines, so that's not a way to distinguish. I think we'd start with separate commands. [03:19] lifeless: (does shelve need a supercapability over commit?) shelve is meant to be a stepping stone to a true undo feature, so it will need more capability than commit has. [04:04] poolie: around? [04:04] hi [04:05] a) quick call and b) still on for slug? I'm meeting horms et all @ the red oak at 5pm if you want a little pretalk social [04:05] a- sure; b- i doubt i can make it [04:30] * spiv heads out for a run and lunch. [05:01] any bzr talks proposed for LCA2010? [05:01] yes [05:01] I put the groupcompress one in a minutes ago [05:02] cool [05:10] thumper, I proposed a talk on Ubuntu Distributed Development. [05:10] jml: hooray [05:10] jml: hey, I just proposed two [05:11] more launchpaddy though [05:11] thumper, [05:12] jml: yes... [05:13] thumper, oh sorry, typo. [05:13] jml: ok [05:23] lifeless: borrow your thoughts again? [05:28] sure [05:30] lifeless: so there is a problem in cscvs something like this: [05:30] a branch is imported from cvs, all fine [05:30] hm [05:30] terminology :) [05:30] a module is imported from cvs, all fine [05:30] a file is created on a non-MAIN branch in cvs [05:31] the import is updated, the catalog gets some entries, all still fine [05:31] the branch is merged to MAIN in cvs [05:31] when cscvs goes to update the import, the Revision that adds the file is a Revision.CHANGE [05:32] so applying it goes boom [05:32] if you generate the catalog from scratch, the Revision that adds the file to MAIN is a Revision.ADD, and it all works [05:32] lifeless: makes sense so far? [05:33] i've chased this as far as CacheGenerator.set_rev_type -- when you do an initial import, this is where the CHANGE gets overridden to an ADD [05:34] so 1.0 of the file is dead [05:34] 1.1 is alive, but datewise there are 1.0.1.1 versions alive before hand? [05:35] it makes sense to me; the incremental analysis is incorrectly thinking the CHANGE can be applied to trunk. [05:35] lifeless: well, cvs has 1.1 not 1.0, but yes [05:36] magic black holes aside [05:36] ;) [05:36] lifeless: http://pastebin.ubuntu.com/238150/ <- the full log [05:38] lifeless: so i'm currently thinking that set_rev_type should dip into the catalog to check for this case, but i've nfi if that's at the right level [05:40] it should be already [05:40] but yes, I think you're in the rightish spot [05:40] its cscvs, by definition you're in the right spot [05:45] holy crap, my fix works! [05:45] the complexity is all kinds of wrong, but nm that [05:46] i am sorry [05:46] its a _very_ organic codebase [05:49] * lifeless is not here anymore (\o/ starting at stupid o'clock) [05:51] thanks for being a teddy bear [05:51] anytime [05:51] however, right now, I has talk to finish. [05:51] so, I actually mean, anytime except now. [05:52] lifeless: has anyone played with inotify and bzr combo? [05:52] arjenAU: I wrote an inotify watcher at guadec 2008 [05:52] dunno were it went... [05:52] arjenAU: but that was for repositories [05:52] there is a mail sender demon that uses inotify to detect changed branches too [05:53] lifeless: pondering it for redundant webservers [05:53] arjenAU: how do you mean? [05:53] auto-syncing them, but with revisioning and through bzr rther than rsync [05:54] just talking static files and php scripts, not db data ;-) [05:54] oh hmm [05:54] probably a little shell love could glue them together well [05:54] a little program to watch for changes and run bzr update; bzr commit [05:55] myself, I'd just deploy via bzr upload to both servers [05:55] with a push trigger. and it'd need to make sure of conflict resolution etc [05:55] and smack, hard, anyone touching them otherwise [05:55] yea not disagreeing there, but there are other uses... pmwiki for instance uses plain files by default rather than a db. [05:55] right [05:56] which has benefits. [05:56] surely it has a hook to call into things on changes? [05:56] yep it has, but inotify would solve it more generically [05:56] with risk though [05:56] regardless of which stupid app the server has. [05:56] inotify has some latency, and you could record inconsistent state [05:56] yes, hence the pondering and asking you ;-) right now it's an evil thought. [05:57] anyhow, I don't know of anyone doing this particular scenario, but bzr can coexist with inotify in python progreams - thats known for sure :) [05:57] yaya [05:57] there's a pyinotify too [05:58] yes, using that [05:58] lifeless: already using etckeeper with bzr. rocks. [05:58] nice! [05:59] I suggested something like that years ago except only bk was around then. happy someone actually did it and integrated with apt and such. [05:59] it's like essential on a box. shouldnt be without it [06:20] hi arjen [08:58] spiv - did your comment before mean that you emptied the mailman greasetrap? [08:59] poolie: no, just that I noticed the list admin mail about it. [08:59] :/ [08:59] it's such an annoying chore [08:59] i'll do it [08:59] Yeah, it sucks. [09:00] geez, look at them all [09:00] Are we still getting bazaar-ng@ mail forwarded to that? If not then decommissioning might cut down the problem a little. [09:01] i think not [09:03] i can't believe our spam system thinks all this crap about acai berries is relevant [09:14] spiv, i might call it a day [09:16] poolie: ok. Have a good weekend. [10:40] hello, is bzr supposed to fail when there's no disk space available? [10:40] http://pastebin.mozilla.org/665240 [10:42] Well, I wouldn't expect it to _succeed_ :) [10:42] I don't think python has built-in support for growing hard drives. [10:45] well... as an end user, i expect that 'st' is a readonly operation [10:45] * timeless_mbp gets out an end user's list of unreasonable expectations and points to this one [10:45] Well, it's potentially a write operation, since it may want to rewrite the dirstate file about the checkout (I don't think it does every time there are possibilities, for efficiency reasons). [10:46] In this case, though, it blew up on writing the logfile. In that sense, _every_ bzr operation writes. [10:46] Even 'bzr rocks', which is as near a no-op as imaginable, writes an entry into .bzr.log. [10:46] is there a --please-do-not-right [10:46] or --please-do-no-write [10:47] There's no general such option, no. You could hack around this _particular_ case by seeing the BZR_LOG env variable to something like /dev/null (or something on a partition with space). [11:02] so, this is a design decision, and not bugworthy? [11:05] Well, the two aren't necessarily exclusive. [11:05] It _is_ a conscious decision. That doesn't mean it can't be changed, though I wouldn't expect this one to be. [11:06] If it's actually a significant problem or a big surprise for you, it's worth registering in a bug or on the ML; the decision would certainly never be changed if nobody argued against it. [11:07] essentially my system has a bunch of version controlled directories [11:07] they automatically grow with changes from "upstreams" [11:08] i was looking for trees which had changes, to decide whether i could delete them (if there aren't any changes in the tree, i could get it back later, when my disk space problems were resolved) [11:08] .bzr.log won't grow without bounds; bzr rotates it when it gest to a few megs. [11:09] You can use $BZR_LOG to shut it off temporarily, or rm the existing one/backup manually to free up a little space. [11:09] in this case, i'm pretty sure my repositories were fairly tiny [11:09] they were network-manager and network-manager-gnome [11:09] (stat may still try to write metafiles and fail if the partition is full, but one problem at a time) [11:09] and had only a couple of uses [11:09] sorry, i had to delete stuff, and the bzr repos were going to go, once i found the files i needed :) [11:10] The error you got isn't from writing anything in those branches, it's from the ~/.bzr.log (though that may be the same partition) [11:10] So `env BZR_LOG=/dev/null bzr st` would get you past that at least. [11:11] -rw-rw-r-- 1 timeless timeless 168K Jul 31 13:35 /home/timeless/.bzr.log [11:11] File a bug with the stacktrace anyway; we should probably handle it a little more gracefully. [11:11] * timeless_mbp puts on a clueless hat [11:11] "where's your bug tracker?" [11:11] https://bugs.launchpad.net/bzr [11:13] thanks [11:13] * timeless_mbp goes to find the password [11:15] heh, it seems i've filed a couple of bugs against bzr :) [11:15] oh, no [11:15] it seems i can't understand launchpad's UI.. great [11:19] Don't think that makes you special :p [11:21] yeah, probably not [11:22] https://bugs.launchpad.net/bzr/+bug/407295 [11:22] Launchpad bug 407295 in bzr ""bzr st" failed to handle No space left on device for ~/.bzr.log" [Undecided,New] [11:22] anyway, thanks. have a good weekend or something [13:06] does bzr-keywords work well? [13:13] In itself, it seems OK. But various issues in the filtering layer keep it from being really useful. [13:13] as long as it doesn't break anything :) === sabdfl1 is now known as sabdfl [13:47] are there any docs about the 2a format and a description of stacked branches? === mrevell is now known as mrevell-lunch [14:13] Louder [14:13] Oops === mrevell-lunch is now known as mrevell [15:21] Hi all, quick question. When contributing to a project generating a bundle sent by mail for a feature I added [15:22] if I want to work on a new fix feature meanwhile it's being reviewed, should I remove my branch and start from scratch again so that all bundles I m pushing are all coming from the original current branch ? [15:26] emmajane, hi [15:26] dolphy, you just create a new branch from trunk, yes [15:26] so your diff is clean [15:27] "feature branches" [15:28] beuno: any faster way to do that than rm -rf and a brand new bzr branch command ? [15:28] dolphy, don't rm -f! [15:28] leave it [15:29] until it gets approved [15:29] you may need to make changes :) [15:29] branch should be pretty fast if you're using a shared repository [15:49] Hi! Do you usually also put compiled binaries under revision control? [15:49] Generally not [15:50] But as with general vauge questions you'll get general vague answers. :) can you be more specific about your use case? [15:50] anything automatically generated [15:53] LeoNerd: no special use case. Just this one: http://bazaar-vcs.org/Workflows#Solo. [15:53] Oh.. well, generally, don't then. [15:53] Half the point of a DVCS is you can do things like branch and merge. bzr won't be able to merge a compiled binary. [15:53] Best just to keep the source which it can merge, and have the binary handled separately by some build system. [15:54] LeoNerd: But I do put binary files like images under Revision control? [15:54] Well.. again.. it's partly up to you. bzr -can- store binary files... it's up to your situation if that's a good idea. [15:54] There can be valid use cases. E.g. storing GIF images as part of a webapp source. [15:54] or icons for a qt programm. [15:55] Indeed. [15:55] I wonder if you could bolt on that Google x86-binary-diff algorithm [15:55] ok, thanks. In what use case *would* you store compiled binaries? [15:55] Or something that unpacked JAR files and diffed the classes before [15:55] homy: Maven repository? [15:55] homy: Backup archive? [15:56] homy: I;m storing compiled binaries, but that's because I'm using Bazaar as an update mechanism for my users on a particular project - and the binaries are not in the source tree [15:57] homy: thinking about it I could probably just install Maven on their machines and make them run a maven goal to update their software... [15:58] .. they could have a working tree of the sources [15:58] But the project is basically done with now [15:58] sorry, what is "maven repository"? [15:58] Maven is a build-and-dependency system, primarily for Java applications [15:58] poolie, pong [15:59] beuno, hey :) [15:59] the same as apache maven? [15:59] homy: Yes [15:59] homy: We're using Apache Archiva as our repository [16:07] emmajane, how's your day today to have a call? [16:32] beuno, pretty good. I'm just dealing with allergies right now so I'm snuffling lots. [16:33] emmajane, in 2 or 3 hours would be great for me [16:33] beuno, that would be just after lunch which could work for me nicely as well. [16:33] emmajane, perfect. Lets ping-pong later then :) [16:33] beuno, sounds good :) [16:53] I have a development branch; which is out of sync with a production branch. I want to merge some changes (entailed in 2 revno's) from the development into the production branch; but only the changes entailed in those two revnos. Anyone know how that can be done ? === deryck is now known as deryck[lunch] === beuno is now known as beuno-lunch [18:00] sidnei: ping [18:01] does bzr+ssh:// require server software other than ssh? [18:06] Tak: bzr installed on the remote end [18:06] Tak: or well, invokable. bzr_remote_path=~/src/bzr/bzr.dev/bzr works too [18:08] ok, but there doesn't have to be any kind of server running? [18:08] not like svnserve [18:16] Tak: no, bzr is just started up over the ssh session and shut down again === deryck[lunch] is now known as deryck [18:26] cool [18:26] is it possible to preauthorize a password with bzr+ssh using the auth mechanism? [18:27] Isn't that what an ssh key is for? [18:29] heh, not possible sometimes === rockstar` is now known as rockstar [18:36] jam: pong [18:38] hey sidnei, I was hoping we could get buildbot working to build the latest installer [18:38] have you done anything with it recently? [18:39] jam: not recently no, but i haven't forgotten about it. [18:39] so at this exact moment I'm a bit preoccupied with something [18:39] but in about an hour it would be nice to work on it with you [18:40] jam: ok, i should get to a stopping point in one hour too [18:42] sidnei: ok, I'll try to ping you if I don't hear from you first :) [18:42] jam: awesome, thanks! [19:26] hi, I've a problem, I've modified source files wrongly, it was after a local commit but before pushing on lauchnpad, does a revert command will do the trick, that is ignoring my last modifications? [19:27] I tried to push directly (since I did not commit the changes), but it says: bzr: ERROR: These branches have diverged. Try using "merge" and then "push".1 [19:28] but I certainly not want to merge I just want to ignore these last modifications [19:28] nilg: "bzr uncommit" [19:28] hello everybody [19:28] or maybe "bzr pull --overwrite" [19:29] how to export a part of my bzr branch to a svn repository without lose of history [19:29] ? [19:29] blackxored: what part? [19:29] a debian/ directory without the .bzr/* files at the root [19:30] blackxored: what does the repository actually consist of ? [19:30] the bzr one, I mean [19:30] SamB, no this will ignore my last commit, right? but I don't want this I want to ignore my last changes not committed [19:30] nilg: oh! [19:30] well, the diverging has nothing to do with that [19:31] run "bzr missing" to see how they diverged [19:31] and I'm scared to do bzr revert and loose my last commit [19:31] bzr revert doesn't lose you commits [19:31] only "bzr uncommit" or "bzr pull --overwrite" [19:31] (and you can still *probably* find them again even then) [19:31] SamB, I got this branch: rootdir => .bzrignore and etc debian/ dir I need to push the debian dir only without the .bzr oens [19:32] blackxored: you can't skip .bzrignore without losing history [19:33] SamB, bzr revert has exactly what I wanted, thank you so much!!!! [19:33] then .bzrignore has to be checkout? [19:33] ci,I mean [19:33] the .bzr directory, though, isn't part of the bzr-managed tree -- it's where bzr keeps it's notes -- so that won't show up if you just "bzr push" to the SVN URL of your choice [19:34] hopefully, either your bzr repository originally came from the SVN repository or the SVN repository is empty? [19:37] * SamB wonders what exactly a "chk" *is* [19:37] SamB, the svn repo is empty [19:37] blackxored: so, why does it even need to be an SVN repository? [19:38] SamB, because is where the team is [19:38] anyway, my three is something like .bzr .bzr-builddeb com debian edu org .pc , and I only need to push debian/ [19:38] blackxored: and do you have bzr-svn installed, and is it a SVN 1.5 (or greater) format repository? [19:38] yes it is [19:39] hmm, why do you only want to push the "debian" directory? [19:39] because I'm doing debian related work and that's all I need to commit [19:39] I think it would make a lot more sense to keep using the bzr repository if Debian makes you jump through so many hoops to use SVN [19:40] SamB, sure but I'm part of a team [19:40] SamB, so solutions/? [19:40] sidnei: ping for great justice [19:40] SamB, I just want to keep history under debian [19:41] well, you could either commit it all, or you could lose some of the history by filtering the branch ... [19:41] SamB, and push debian [19:41] jam: wrapping up, 2 minutes [19:41] can you make another branch of the svn repo, merge in just the commits to debian/, then push those back up to the repo? [19:41] k [19:41] Tak, right, the question is how? [19:41] but that would probably make it very difficult to collaborate with Ubuntu ... [19:42] was your bzr branch originally branched from the svn repo? [19:42] Tak, no It was private [19:42] blackxored: it would make things way more complicated unless the people who made the bzr repository aren't going to continue using it ... [19:42] SamB, I hosted my branch in launchpad initially [19:43] SamB, I could assume that won't be used anymore [19:43] I'm not sure if you can automatically merge two branches that don't have the same ancestor... [19:43] blackxored: and did you already try to talk the rest of the team into joining you in using the bzr branch? [19:43] Tak: SVN repo is empty [19:43] Tak: that's why I'm wondering what is so important about using SVN! [19:44] SamB, because the team uses svn! [19:45] blackxored: they can't use anything but svn? [19:45] SamB, I'd be glad if they use bzr, actually, I'll jump and jump and jump... [19:45] SamB, I'm quite new , so won't ask them to switch [19:46] hmm, could you push the branch to the repo, then merge out non-debian/-relevant revisions? [19:46] jam: ok, ready [19:46] * sidnei updates bzr.dev [19:47] the branch has no upstream code [19:47] only debian dirs, and bzr-related ones [19:47] blackxored: com edu and org are debian-related? [19:47] must be a java project ;-) [19:47] I mean, what do they do? [19:48] Tak, is a java project [19:48] blackxored: oh, so there *is* upstream code! [19:48] sidnei: so the first (small?) issue, is that I don't think Tortoisebzr actually makes releases [19:48] * Tak winnar [19:48] those files are ignored [19:48] so we don't really have tags to use [19:48] per se [19:48] is the solution to just force it? [19:49] SamB, *are* ignored [19:49] so...everything but debian/ is ignored anyway? [19:49] Tak, yes! [19:49] jam: what you mean by 'force' it? [19:49] so what's the problem? [19:49] blackxored: so what bzr branch do you want in svn? [19:49] step 1: make that branch [19:50] sidnei: force them to start using tags and releasing [19:50] or faking it my making my own branch with tags in it [19:50] ok, listening [19:50] to date, I've just grabbed whatever the current tbzr tip revision is [19:50] step 2: bzr push svn://alioth.debian.org/path/to/repo/and/branch [19:50] jam: tip would work, but of course it would be best to have a tag [19:51] jam: who's upstream for tortoizebzr? [19:51] random people [19:52] hmm [19:52] It was originally written a while ago, then updated by Mark Hammond [19:52] right now I'm not sure who is really maintaining it [19:52] I've seen updates from both bialix and Naoki [19:53] reminds me, i need to get a hold of all the tortoise kinds of people (there shouldnt be one for each vcs) [19:53] blackxored: if you don't really care about anything but debian/, you could just use jelmer's filtering plugin to remove everything else from the entire history before pushing [19:53] more like one for all of the vcs's [19:54] sidnei: beyond that I think I can go through and update some of the bits. [19:55] jam: how does tagging work in bzr? can you tag a remote branch? [19:55] sidnei: tags are maintained as part of the branch meta-info [19:56] so if you are deleting the target, you can't just set a tag there [19:56] if you were copying into your own branch, then you could have your own set of tags [19:56] sidnei: what is this: [19:56] rem Enable this when this branch is merged. [19:56] rem make python-installer PYTHON24=${settings:python24} PYTHON25=${settings:python25} PYTHON26=${settings:python26} [19:56] rem @if %ERRORLEVEL% NEQ 0 (set BUILD_ERROR=%ERRORLEVEL%) & goto End [19:56] why aren't tags part of the repository ? [19:56] You seem to copy the code from "python-installer" into your own set of lines w/ bdist_wininst [19:56] SamB: read the mailing list [19:57] lots of discussion there [19:57] stuff like, 2 projects using the same shared repo, and using "release-1.2" style tags [19:57] but being different ancestries [19:57] jam: yes! I'm not exactly going to reread the whole thing [19:57] jam: oh, point [19:57] okay, that's good enough for me for the moment [19:57] yeah, there was a *lot* of discussion about possible tag mechanics [19:58] I'm not very satisfied with what we have, but at least we have something. [19:58] and it's not a case where there is an obvious improvement [19:58] jam: hold on, let me finish this thought about tags, then i will look into that [19:58] sidnei: so I'm wondering if I should uncomment the "rem" and then remove the next few lines. [19:58] jam: so just tagging a specific revision (the one included in the installer) of tortoisebzr trunk in launchpad with the installer release version would be enough, if that's possible [19:58] sidnei: I would guess I actually have write access to lp:tortoisebzr or if necessary, I could *get* it. [19:59] jam: seems like you have access. in fact, i now have access to. the owner is an open team *wink* [20:00] wow, that's got pugs beat! [20:00] hmm [20:00] sidnei: what is "gf.recipe.bzr" ? [20:00] now, how to persuade all the different tortoiseFoo teams to work togeth [20:01] I mean, I have joked that if you so much as *sneeze* in #perl6, they will give you pugs commit access, but ... [20:01] jam: it's a buildout recipe that calls bzr [20:01] i managed to end up in the pugs contributors list [20:02] jam: just so the branches to be pulled for the plugins are in the buildout.cfg [20:02]