[04:51] <_Andrew> Hi all, How do I setup the --fixed command so that it works system wide? [04:52] <_Andrew> I want to add a bug tacker for our office so that we can do something like --fixed LR:1234 [04:52] <_Andrew> tracker** [04:53] jml, lifeless: skype apparently crashed [04:55] jml, lifeless: actually nm, not a good use of time [04:55] poolie, ok. [04:56] _Andrew: http://doc.bazaar.canonical.com/bzr.2.0/en/user-reference/index.html#bug-tracker-settings [04:59] jml, lifeless, i was basically just going to say that the matcher stuff seems a bit more wordy to define and use than would really be optimal [05:01] poolie, do you have any thoughts on how it could be better? [05:05] <_Andrew> poolie, Is there a system wide config file? [05:06] <_Andrew> In the documentation it says it can go into bazaar.conf [05:13] _Andrew: i don't think there is at the moment [05:16] <_Andrew> ah, because that's the bit I'm stuck on : / [05:29] is there a bzr equivalent of 'hg rollback' - uncommit the last transaction harmlessly, leaving nothing in history? [05:30] bzr uncomit [05:30] er, spelt correctly [05:30] also, in general what are the bzr 'undo' commands? i'm trying to figure it out from an hg background, where i have hg rollback (undo last txn), hg backout (commit a new entry that reverses a particular commit), hg strip (forcibly strip a revision from history) [05:30] aha, thanks [05:33] You can do "bzr merge -r -2..-3" to merge the reverse of -2 (-2 is the 2nd last commit). [05:34] You can probably use the rebase command (from the bzr-rewrite plugin) to do the equivalent of hg strip, but I haven't looked closely (it's not an operation I've needed to do myself). [05:34] Plus of course 'bzr revert'. [05:35] ah right, found that one [05:37] Note that "bzr uncommit" doesn't strip it from the repository like "hg rollback" does. [05:37] Mostly, bzr users ignore the cruft, since it's not significant unless you commit an ISO or something. [05:38] Peng: it doesn't? it gave me the exact same revision number when i committed it the second time, and bzr log does not show the cruft one [05:38] MFen: Bazaar structures things a bit differently than Mercurial./ [05:39] where would i go to observe this cruft [05:39] MFen: You wouldn't. [05:39] MFen: Well, the heads command from the bzrtools plugin, I guess. [05:39] Peng: so it's dark cruft? [05:42] MFen: yeah. It's still in the big bucket of revisions we call the "repository", but nothing refers to it. [05:43] MFen: in fact, when you do "bzr uncommit", it emits a command that will resurrect it if you want to un-uncommit ;) [05:43] so does it get pushed when changes go out? [05:43] MFen: nope [05:43] oh ok. it's not really that different from hg then [05:44] MFen: Except it still exists. [05:44] no, even with that [05:44] with strip (not 100% sure about rollback), the removed revision is saved in a backup file. but it doesn't ever leave the local clone unless you use it [05:44] <_Andrew> If you uncommit and the commit does it still exist? [05:44] _Andrew: Yes. [05:45] _Andrew: Did you mean "and then commit"? [05:45] <_Andrew> or what if you uncommit and then push your repo somewhere does this dark commit exist in the pushed repo? [05:45] _Andrew: Push only pushes the revisions in the branch you're pushing. [05:45] _Andrew: you push branches, not repos [05:45] (Push push pushy push.) [05:45] _Andrew: and pushing a branch will only push revisions that are part of the history of that branch [05:45] _Andrew: so the short answer is no, it won't exist in the pushed repo. [05:46] Yeah, your version sounds better. [05:46] <_Andrew> ah interesting [05:46] <_Andrew> So this dark commit just exists locally where you did the command [05:47] Unless you pushed or pulled or copied it somewhere else. [05:50] i can see how bzr's integration with launchpad could be useful. it is convenient to say "related to this branch over here [05:50] hi all [05:50] seems like a lot of server maintenance though. i bet it's a headache keeping all those services working together === igc1 is now known as igc [05:50] igc: hey, happy new year! [05:51] hi spiv! [05:51] ditto [05:52] MFen: no worse any other 400+ kLoC project I'm sure ;) [05:53] (Although given that ohloh thinks that source includes -3153 lines of comments in SQL, maybe I shouldn't trust it so much...) [05:53] every line of sql is so obscuring that it actually destroys 10 lines of comments [05:54] if you get enough sql in one place, it starts eating python docstrings too [05:54] :) [05:54] god help you if there's perl. [05:54] Idea: Embed Perl in SQL! [05:55] MFen: https://www.ohloh.net/p/launchpad/analyses/latest says 3 code lines of Perl, and 54 comment lines... [05:59] heh i like that the html line count is also negative [05:59] that's because HTML is not code. [05:59] (but it does have comments.) [06:26] jml: skype death? [06:48] lifeless, spiv does bug 501254 ring any bells? [06:48] Launchpad bug 501254 in bzr "NoSuchRevision after parallel commit to 2 branches in 1 repos" [Undecided,New] https://launchpad.net/bugs/501254 [07:20] poolie: not offhand [07:21] hi all, and Happy New Year ! [07:21] hello vila! [07:51] poolie: not for me either... but 1.17 is relatively old now. [08:34] night all [08:48] hiya [08:48] is there some kind of work-around when you're not able to branch or merge from a "bazaar-ng loom branch format 7" branch with Bazaar 2.0.3? [08:49] dholbach: ....Install the bzr-loom plugin? [08:50] Peng: does that loom-ify all kinds of branches? [08:51] I wouldn't like others to run into the same problems just because I installed the plugin [08:51] ... and pushed a couple of changes somewhere [08:52] dholbach: loomification is always an explicit step [08:52] lifeless: alright, thanks for that [09:32] Hi I'm considering bzr for my version control needs and found out that the Visual Studio integration is quite dated and possibly abandoned [09:33] How well will bzr work with code refactorings (which includes file renames, directory moves etc.) when not done via 'bzr' commands but from within Visual Studio? [09:38] hi there, I'm new to bazaar, just playing with it using the olive gui [09:39] is it possible to sign commits using olive? [09:39] Borek: pretty well [09:40] Borek: 'bzr mv --auto' will do its best to guess what the renames were, even if some edits were made to the contents of renamed file. [09:40] I added 'create_signatures = always' to ~/.bazaar/bazaar.conf and then commits using olive fail when it tries to add the signature [09:41] spiv: thanks for the pointer to mv --auto, sounds like this should do. i'll try, thanks again [09:41] marsilainen: Hmm, that sounds like the right approach. Hopefully someone can help you figure out why that isn't working. Does that work for you if you use 'bzr commit' directly, without olive? [09:44] spiv: hmmm, yes it does - it prompts for the gpg passphrase in the interactive terminal though so I don't know if that could be the issue [09:57] marsilainen: could be, maybe you need to set the signing command too, to use a gpg gui [10:04] spiv: ah yes, thanks - I installed gnome-gpg and set the signing command to use that - seems to work now :) [10:04] spiv: thanks for your help [10:10] marsilainen: you're welcome :) === mrevell is now known as mrevell-lunch [12:14] vila, hi [12:29] ok, so I'm using bazaar for the first time... I'm starting a project which will just have me working on it initially but will then (hopefully) widen to have others working on it too [12:30] if I want others to be able to view all my revisions sometime in the future, what should best-practise be from the start? [12:30] should I just work with bazaar locally? or should I push each change to a server copy? [12:32] It doesn't really matter whether you push now or later. [12:33] ok [12:33] Of course, you'd have trouble sharing later if you just worked locally, and then your local system blew up. [12:33] heh :) [12:35] maybe I will just use a remote repository in the first place [12:35] at least then the workflow seems more like what I'm familiar with from svn etc [12:37] marsilainen: I'd recommend having a remote copy somewhere, even if you just use it for backup purposes [12:37] marsilainen: but there's some good workflow ideas in the user guide [12:38] yeah, makes a lot of sense, and that's what I'd normally do with something like svn. I just wasn't sure if that was the appropriate way of working in a distributed version control like bazaar [12:39] I'm reading http://doc.bazaar.canonical.com/bzr.1.18/en/tutorials/centralized_workflow.html now and I will probably go with something from there [12:39] thanks for the help [12:39] * Kinnison finds that the bzr 'centralized workflow' doesn't work well for him. [12:39] one of the huge benefits of bzr over the other DVCSs is that it is incredibly flexible with the workflow [12:40] * Kinnison has been using bzr since it was barely able to revision-control itself though :-) [12:40] heh [12:53] vila, when you get a chance, and you take a peak at: https://code.edge.launchpad.net/~beuno/bzr-upload/bug-499525/+merge/16552 [13:29] happy new year bzr! [13:32] happy new year bialix [13:33] and you roo [13:33] and you too [13:33] sorry [13:34] no problem [13:45] hello. i'm trying to use bzr-git here to push to git-hub, but i've noticed that dpush seems to be using the wrong plugin: [13:45] in bzr.log: [13:45] 0.851 bzr-svn: using Subversion 1.5.6 () [13:45] the URL is however: git+ssh://git@github.com/Noldorin/IRC.NET.git [13:46] what am i doing wrong here? [13:55] beuno: I saw it, it's on my TODO list. We should reuse more bzrlib code, but it's not as easy as it should. But using is_inside_any looks... risky, are you sure you won't get false positives with it ? [14:01] vila, I started writing something that was almost the same, so I read through it and re-used it [14:01] beuno: you mean is)inside_any [14:01] beuno: you refer to is_inside_any ? [14:01] vila, yes [14:02] hey all, I've got a question about the capabilities of the shelf API [14:02] beuno: my concern is that bzrlib doesn't do that and I don't want to have a divergent implementation (users will get confused, we'll need to document the differences, etc) [14:03] is it possible to unshelve individual changes and show shelved changes as a flat set [14:04] Pilky: unshelve individual changes: probably with some work (depending on the granularity) [14:04] Pilky: you can *shelve* individual changes, not unshelve them [14:04] Pilky: what do you mean by "a flat set"? [14:04] vila: with the API [14:04] happy new year too :-) [14:05] well I'm trying to design a UI for it in BazaarX, and I'm looking at showing the shelved changes in a list and unshelved changes in a list, and you can drag changes on and off the shelf [14:05] james_w: given what is exposed from command line, I suspect that's also true for the API. [14:06] Pilky: what do you call an individual change ? [14:06] vila, bzrlib doesn't do what? [14:06] vila: yes, the API doesn't provide for it, but if you make the merger then you can do .set_interesting_files() for the files level. [14:06] beuno: use is_inside_any [14:06] vila: what the shelf API classes as an individual change [14:06] for hunks you would have to create a memory tree and then re-shelve hunks back off it or something [14:07] I imagine it is tricky but possible [14:07] right [14:08] doing it for individual changes should be straightforward [14:09] ; bzr shelve --all; ; bzr shelve --all; will show up as two things [14:09] manipulating those two things as they are should be straightforward [14:09] beuno: bzrlib builds a globber and then try matching paths against it, I think that generalizes what you tried with is_inside_any, but I need to check more carefully what you did and what bzrlib does [14:10] vila, ok. So I leave it with you? [14:10] james_w: yeah possibly [14:10] beuno: yup, I'll try to review asap [14:11] vila, thanks :) [14:11] beuno: thanks for working on it :-D [14:12] vila: Hi [14:12] jelmer: hey ! [14:13] vila: First of all, happy new year :-) [14:13] Do you have some thoughts about this, is it something we can fix: [14:13] jelmer: same to you :D [14:13] wilmer@ruby:~/src/bitlbee/libpurple$ bzr pull http://code.bitlbee.org/wilmer/libpurple/ [14:13] http://code.bitlbee.org/wilmer/libpurple is permanently redirected to http://code.bitlbee.org/wilmer/libpurple/ [14:14] vila: Why is the trailing slash lost somewhere? [14:14] jelmer: it's a one-line fix to bzrlib to make it stop to remove that trailing slash [14:15] I remembered abentley and lifeless talking about it.... months ago at a sprint, but it seems that the patch got lost somehwere.. [14:15] hi jelmer. i think i've figured out what the problem was [14:15] ...well, nobody looked at the consequences if any to be honest [14:16] vila: Ah, thanks [14:16] Noldorin: Cool, what was it? [14:16] james_w: might be worth just changing how the UI works to fit in with how it is intended to work, so that it doesn't confuse bzr users. [14:16] jelmer: but my recollection of the problem is that many places handle (or not) the final slash, and I've always pushed that item down my stack... [14:16] jelmer: well, it's not solved....but what is happening is it seems to be using the bzr-svn plugin still :S [14:16] in bzr.log: [14:16] 0.851 bzr-svn: using Subversion 1.5.6 () [14:17] even when i use git+ssh url [14:17] Noldorin: That's only loading the svn plugin, not using it. [14:17] hmm [14:17] so maybe not :S [14:18] It's correct, the bzr-svn plugin has to register itself on startup (bzr-git does something similar) [14:18] i see [14:19] jelmer: http://pastebin.com/m4c073a7 is the last part of the log [14:28] jelmer: does that help? [14:29] Noldorin: no idea, sorry [14:30] ok no prob === weigon__ is now known as weigon [15:54] vila!!! [15:55] nice resolve proposal, thanks [15:55] james_w`: glad you like it :) [15:56] it's a small thing, but will be very useful [15:56] james_w`: it was pretty hard to isolate, but more can (and will) be done [15:57] oh, sorry, I didn't mean to detract from your effort :-) [15:57] as said in the cover letter, there are many hints already inserted in the relevant places [15:57] I meant that it's not a headline feature, but will be very useful [15:58] james_w`: I think so, the tree-shape conflicts are confusing for many people (including me no later than 2 hours ago :) [15:58] heh [15:59] james_w`: and for people that have to deal with tenths if not hundreds of conflicts, I think it's a bit more than a small feature :-D [16:00] All features are small. Until you need them. [16:01] . o O ( Small hammers ? Really ?) [16:01] If the only tool you have is a hammer, every problem looks like a thumb. [16:02] jelmer: pong ;-P [16:03] Tak: heh, that was a roundtrip of a couple of days ? :-P [16:09] at least [16:09] I'd better check my connection === beuno is now known as beuno-lunch === NfNitLoo` is now known as NfNitLoop === NfNitLoop is now known as Guest66763 === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley === beuno-lunch is now known as beuno === Guest66763 is now known as NfNitLoop [17:28] hello [17:28] i've accidentally just done a merge from a remote branch... [17:28] which has just renamed all my working files to .moved [17:28] how i restore these .moved files to be the normal ones? [17:28] (overwriting the ones i just pulled from the remote branch) [17:28] ? [17:30] revert. [17:30] But if it really renamed a huge pile, that's probably a sign that something's not what you think it is. [17:33] fullermd: revert reverts to my last commit [17:33] i made changes, then updated before i committed [17:34] Well, revert on the individual files. [17:34] hmm ok [17:37] But still, having a big number of files conflict like that is a big flashing danger sign anyway. [17:39] well, he said the merge was accidental === kfogel is now known as kfogel-lunch [17:46] fullermd: yeah, revert isn't quite what i want === mrevell-lunch is now known as mrevell [17:51] basically i want to find a way to revert to all my .moved files/dirs === Kinnison_ is now known as Kinnison === scanferlato_ is now known as scanferlato [18:14] jelmer: i've given up on git for the moment and am just trying to get bzr-svn to work... [18:14] the problem is just that i get this error when i try to push: bzr: ERROR: These branches have diverged. [18:16] good afternoon #bzr world [18:16] heya jam [18:19] how do I solve this: http://pastebin.ubuntu.com/351370/ [18:19] "different rich-root support" error [18:19] kirkland, upgrade locally or remotely === deryck is now known as deryck[lunch] [18:20] beuno: "bzr upgrade" ? [18:20] kirkland, if you have 2.0+, yes [18:20] beuno: karmic [18:20] /tmp/tmp.7XKeNG4ej8/ubuntu is likely the old one [18:20] kirkland, yes, just plain upgrade [18:21] beuno: cool [18:23] Noldorin: what are you trying to do exactly? [18:24] jelmer: simply push to a svn server [18:24] (on codeplex) [18:24] just created a project [18:24] Noldorin: are you pushing a new branch? [18:24] yep [18:24] https://ircdotnet.svn.codeplex.com/svn [18:25] Noldorin: and you're pushing to https://ircdotnet.svn.codeplex.com/svn/trunk ? [18:25] yep [18:25] erm [18:29] jelmer: heh, seems the problem has stopped now, never mind :) === tchan1 is now known as tchan [18:37] jelmer: well, in case it helps: the problem with bzr-git and the publickey being denied happens for whatever url i put in :S [18:37] seems we're both clueless here though [18:39] Noldorin: I suspect it's windows specific [18:39] jelmer: yeah. well, i'll leave it to you if that's alright... [18:39] jelmer: feel free to ping me any time if you want me to do some testing though [18:40] hey, is there any way to import a single file and it's history into another tree that's unrelated to the tree that file came from? [18:41] elmo: only by merging the other tree and then reverting all of the files other than the one you want to merge [18:41] failcats [18:41] jelmer: ok, thanks [18:45] elmo: Alternate phrasing: files don't have history; history has files. [18:45] I think 'failcats' is shorter and more to the point [18:45] ;-) [18:45] Yes, but such a slur against the feline race is likely to get you murdered in your sleep by one or ten of them. [18:48] :) === deryck[lunch] is now known as deryck [19:01] Its normal for BZR to take 95% CPYU for a long time when bzr log of a specific project sub directory? [19:04] phoenixz, it's not [19:04] what version of bzr and what format is the branch? [19:04] beuno: should be one of latest, one sec.. [19:05] beuno: 2.0.0 [19:05] phoenixz, and what does [19:05] "bzr info -v" say? [19:05] beuno: bzr log . [19:06] beuno: http://pastebin.com/f65622fb1 [19:06] so it's the latest and greates [19:06] *greatest [19:06] phoenixz, is the branch public? [19:07] beuno: public? nah, its on my local computer [19:07] phoenixz, I'd file a bug about it, but it may be hard to debug without the actual branch [19:08] beuno: bzr log works like a charm though.. bzr log in a sub directory makes it hang like this [19:08] right, it's a more expensive operation, but it shoulldn [19:08] beuno: well, problem is that I cant publish (all) the code.. I'll try to have the open source part republished soon [19:08] be so bad [19:09] jam, you around? any idea how to transform phoenixz's issue into a bug report? [19:11] just a sec, open bug [19:12] jam: this is an existing bug? [19:12] bug #374730 [19:12] Launchpad bug 374730 in bzr "log dir is slow in development-rich-root" [Medium,Fix committed] https://launchpad.net/bugs/374730 [19:12] This should be in 2.0.1 [19:12] well, my phase-1 fix is supposed to be there [19:13] phoenixz: ^^ you might try upgrading your bzr and see if it helps [19:15] phoenixz: If you look at my timings, for small subdirs you can see: [19:15] "time bzr log -n0 --no-aliases tools" went from [19:15]   real 5m16.959s [19:15] down to [19:15]   real 0m37.888s [19:15] for a larger dir (bzrlib) it was only ~2m [19:16] wow [19:16] jam: wow.. [19:16] jam: well, this project has about 40.000 files so I expect it not to be realtime but Ive b een waiting 5 mins with bzr on 95% :) [19:17] phoenixz: how big is the subdir you are looking at? [19:17] jam: not big, like.. total of 7 directories and 30 files in the entire tree.. [19:18] phoenixz: definitely try bzr 2.0.1+ (or 2.1*) [19:18] jam: will do [20:29] hi, what is the current way to create a bzr branch? [20:29] i have an old copy lying around, but it won't update [20:30] "permamently moved to xxx. not a branch: xxx" [20:31] knittl, a new branch? bzr init . [20:31] beuno: no, i want to clone the official bzr repo [20:31] knittl, bzr branch lp:bzr [20:32] can i change the remote of my current repo? [20:32] i don't want to pull everything again [20:33] knittl, bzr pull lp:bzr --remember [20:33] great, thanks [20:35] If it's old enough to be using a nonexistent URL, I tend to suspect it's also a pre-2a format branch too. [20:36] And re-pulling everything is probably faster than doing a local upgrade, unless you have a pretty slow connection. [20:36] fullermd: it's alreaty finished pulling [20:36] Oh. Then ignore me 8-} [20:36] * already [20:37] need to clone all dvcs [20:37] :) [20:37] phew, hg was fast [20:39] knittl: why clone all of them? [20:40] i'm writing a paper [20:40] and i want to have the latest incarnation of each [20:40] on what? [20:41] on dvcs's [20:56] knittl: ooi, what's your definition of "all" ? [20:56] xD git, hg, bzr, maybe darcs [20:57] ah, so 'some' [20:58] the most popular ones [20:58] and open-source [20:59] monotone if i have time === james_w` is now known as james_w [21:06] knittl: well, so what is the exact topic? [21:06] analysis and comparison of distributed version control systems [21:07] i see [21:07] i suppose you wont propose ideas for conceptual unifications [21:07] (im writing a vcs abstraction lib, good ideas might be helpfull) [21:08] no *g* [21:13] is there a bzr online browser? like git's gitweb [21:14] knittl, yes [21:14] loggerhead [21:14] for the official repo? [21:14] this is a working version: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk/changes [21:14] this is for the official repo: http://bazaar.launchpad.net/~bzr/bzr/trunk/changes [21:15] i need to browse commits by id [21:15] sure [21:15] http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/pqm@pqm.ubuntu.com-20090903012533-qc6kvh5ujgk8042p [21:15] http://bazaar.launchpad.net/~bzr/bzr/trunk/revision/$id [21:16] you can run loggerhead locally if you want [21:16] it will probably be much faster :) [21:19] no, i need official urls for my paper [21:21] hi all [21:21] http://pastebin.ubuntu.com/351433/ <- anyone have an idea what that would be? i'm quite confused :) [21:22] permission problems with the lockfile/folder? [21:23] i'd think permisions would give -EPERM no? and it's a fresh branch, so nothing should have changed perms [21:24] knittl: I don't know what you mean by official urls [21:24] knittl: its a distributed system [21:24] lifeless: beuno's urls are perfect [21:24] i know it's distributed. i understand the idea behind distributed systems [21:24] oh nevermind [21:24] i am an idiot [21:24] hi knittl, mind a question? [21:25] scanferlato: what is it? [21:25] * dobey suddenly remembers that the bzr gtk things hold the lock [21:25] sorry to bother :) === scanferlato_ is now known as scanferlato [21:28] i.e. when you checkin, the repository stores the checkin and mtime of the file [21:29] when you chekcout/branch/export, it gives you three choices for the mtime: current, checkin, and last modification [21:30] AFAIK, only one VCS has it, and it is not a good one (Visual Source Safe) [21:30] … and the question is? [21:30] it's never good to rely on mtimes [21:31] but having certain mtimes for files might be a good thing for build systems like make [21:32] yes, that's when you uses a DVCS to store source code. But you can store other things as well [21:32] I don't think bzr stores mtimes in the first place. [21:32] the question is: do you know of any DVCS that has this feature? [21:33] when is mtime important? [21:34] I don't know of any that store mtime. I'd be a little surprised to find out any did. [21:34] I'm pretty sure none use the commit time by default. Not sure if any have the option. [21:34] fullermd: you *can* use the commit time, but no, we don't store the last-modified time at commit [21:34] when you store e.g. a Word document, and your company policy is to print the date of last change on the first page of the document [21:35] scanferlato: wouldn't that either be a Word feature, or something you have to do before checking it in anyway? [21:35] you could always do "bzr log FILE" to find out after the fact [21:36] jam: even if you have tens of documents in several folders? [21:37] so, if it is supposed to be in the document, that obviously needs to be done before commit [21:38] and if you had to do it after the fact [21:38] you would probably prefer to give it the [21:38] yes, it is the mtime set by Word itself, when you save it [21:38] timestamp of the actual content change [21:38] rather than the time that you added the timestamp [21:39] scanferlato: so Word has an option to include the mtime of the file as a date-stamp in the document? [21:39] Wouldn't it record an actual 'last modified' time internally? [21:39] since if I send a file to you [21:39] without you changing it [21:39] just saving [21:39] would create a new mtime [21:39] by OS rules [21:39] yes, it is something like a macro or an internal variable [21:39] my point is to be valid, it really has to be an *internal* variable [21:39] using the filesystem's mtime is bogus [21:39] for *lots* of reasons [21:40] copy file.doc newname.doc [21:40] etc [21:40] I have to check this [21:41] there's no way in word to use last mtime [21:41] it's possible to use a fixed time or "current" system time [21:41] the point is to get the file from the repository exactly as it was when I check in. Including the timestamps [21:43] *checked [21:43] is this even possible from an os standpoint? [21:43] bzr log --last 1 FILENAME | munge to date | xargs touch FILENAME [21:43] knittl: you can set mtime usually [21:43] but not atime [21:43] or ctime [21:43] scanferlato: note that we also don't version anything but whether it was executable [21:43] so we won't give you group or user [21:44] or permission bits [21:44] (acls for Windows users) [21:44] no problem, so far I did not need permissions [21:44] hm… [21:45] group, user, etc. Just the timestamp of the last change [21:45] scanferlato: so you could get the commit timestamp out, especially if you use bzrlib's code. [21:45] but there isn't a way to tell bzr to touch all the files with that time [21:46] spiv: /wave [21:46] I believe CVS is able to do that [21:46] jam: hey [21:47] just saw you on the bugtracker, figured I'd say hi :) [21:47] jam: I just reviewed your fix for 'cdef void' [21:47] jam: short version: it's good, but you missed a bit ;) [21:47] jam: (as in, it fixes this bug, but it looks like the same bug is lurking elsewhere in our pyx files) [21:47] spiv: will respond when I see the message [21:48] jam: you'll particularly love the instance of it in _knit_load_data_pyx I think ;) [21:48] spiv:Don't care about _knit_load_data, tbh [21:48] *old* code, only used in knit formats [21:48] which are 2 major versions old now :) [21:48] Yeah, and its not an important bug even then... but still funny. [21:48] scanferlato: CVS doesn't store *time. cvs co does set the file timestamp to the commit time. [21:49] I believe CVS is able to do that; [21:49] sorry [21:49] i don't believe in cvs, sorry [21:50] fullermd: yes, CVS exports/checkouts set either current or commit times [21:52] knittl: ideally we should not believe in anything, but use whatever works well and does what we need [21:53] cvs does not work well for me [21:53] ^^ [21:53] so far only VSS does what I need, but I refuse to use it [21:54] morning [21:55] hi spiv, jam [21:57] Well, *I* believe in CVS. I've seen the fire stirring in the belly of the beast... [22:04] james_w: hi [22:04] hi lifeless [22:04] james_w: is my ppa watching bzr builder branch merged ? [22:04] not yet [22:05] ok [22:05] is there more I need to do than nag? :) [22:06] g'night all, and thanks for your time [22:06] did you say that you had fixed some of the issues? [22:07] james_w: yes, I did [22:08] that will help then [22:09] Its important to the dx team that this works, and for stopping it be adhoc-deployed by being able to switch to packaged releases of buidler [22:09] As I've said I'm happy to do fixes to it in trunk too. [22:11] morning igc [22:11] and lifeless [22:11] hi jam igc spiv poolie [22:12] hi lifeless - Happy New Year [22:12] hello igc! [22:12] hi poolie james_w [22:13] hi igc and everyone [22:18] welcome back, all [22:22] hey poolie, didn't think i'd see you tonight [22:41] hi jam [22:41] on phone atm [23:00] jam: still around? [23:01] lifeless: I am right now, but probably not much longer [23:02] was wondering if junitxml + subunit was working better for you now, with the releases I did [23:02] lifeless: I haven't been playing with hudson for a while [23:02] I think it was going in the right direction, but I haven't tested it [23:08] ok, thanks. [23:14] off for now, see y'all around tomorrow [23:14] spiv: you might want to take a look at lp:///~jameinel/bzr/2.0.4-pyrex-propagation [23:14] and tell me what you think [23:15] jam: night === RAOF_ is now known as RAOF [23:30] jam: ok, thanks [23:46] hi spiv, lifeless [23:46] lifeless: quick call? [23:46] sure