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