=== mordred_ is now known as mtaylor
[01:06] <sproaty> how come directories don't have the same revision ID as its children? e.g. I just commited to the dir "whyteboard" and it's last updated on january, rev 170 whereas its contents are at 305. I'd expect the dir to be at 305 too?
[01:06] <sproaty> http://bazaar.launchpad.net/~sproaty/whyteboard/development/files
=== Ursinha-dinner is now known as Ursinha
[01:13] <spiv> sproaty: I think for directories the web viewer only shows when the directory entry itself last changed
[01:13] <spiv> sproaty: so when it was created, or last renamed
[01:14] <spiv> sproaty: I suspect it does that because it's cheaper to calculate than the last revno that any of its contents last changed.
[01:15] <sproaty> yeah true, I guess a  large project with several hundred sub-dirs would take a while to generate the root page :)
[01:57] <Phoenixz> I have a bzr branch with a number of tags. I want my WT to reflect the state of a certain tag, and after that I want the WT to be again in the latest version. How do I do this? I thought bzr switch, but that seems different
[01:59] <fullermd> update
[02:00] <Phoenixz> fullermd: bzr update tag 1.0.3 ?
[02:00] <fullermd> bzr update -r<whatever>
[02:01] <Phoenixz> fullermd: so I cannot specify a tag?
[02:01] <Phoenixz> that would have been sweet :)
[02:01] <fullermd> -rtag:1.0.3 (or possibly just -r1.0.3 in recent enough versions assuming you don't have a revno 1.0.3)
[02:01] <fullermd> (which I don't THINK is possible...  I think the middle number is always natural)
[02:02] <Phoenixz> fullermd:  bzr: ERROR: branch has no revision sven@fs-ex-20100714193341-nxxm4776w97sbaip
[02:02] <Phoenixz> bzr tags shows the 1.0.8 tag to be revision 171.1.142
[02:03] <Phoenixz> bzr update -r171.1.142
[02:03] <Phoenixz> gives same kind of error
[02:03] <maxb> Are you sure? I would expect a quite different error?
[02:04] <Phoenixz> maxb: its whats on the screen.. dunno what it means though
[02:04] <fullermd> Mmm.  That seems to be a bug in 2.1.x....  it works with bzr.dev.
[02:04] <Phoenixz> fullermd: crap.. No way around
[02:04] <Phoenixz> ?
[02:04] <fullermd> It's getting all cranky about revs that aren't on the mainline.
[02:05] <fullermd> Yeah, that's a 2.2 fix.
[02:05] <fullermd> You could use bzr.dev or a 2.2 beta.
[02:05] <Phoenixz> fullermd: now that I have you "on the line" anyway.. do you know a solution to this? I have a framework in a bzr branch, from there I created two other branches that use that framework to create a web system. Works flawless all but for one major problem
[02:05] <fullermd> You could also use 'revert', though that has various uglier sides.
[02:05] <fullermd> Eep!
[02:05]  * fullermd gets off the line!
[02:06] <Phoenixz> fullermd: I created this design because at various times we find bugs in the framework in the projects using that framework. So we fix the framework bugs in that project, so that we later can merge those fixes back into the branch that only contains the framework
[02:07] <Phoenixz> fullermd: problem is, the merge from the project to the framwork branch will also copy all changes that are specific to that project to the framework branch, and I dont want those.. Up until now, I used "bzr revert" to kick out those changes, but it gets a bit labourous.. isnt there a better way to fix that?
[02:08] <fullermd> Yes, that's ugly.  Doing that 'revert' has a lot of ugly side effects.  For one thing, you may not have the files in that new rev, but they're all in the history.
[02:08] <fullermd> For another, that means the next merge of that framework up into the project will delete all the files too.
[02:08] <fullermd> Ideally, you'd do it initially in the framework branch, then merge up as needed.
[02:08] <fullermd> Of course, in practice that ends up impractical a lot of the time.
[02:09] <Phoenixz> fullermd: yeah, so I've noticed.. once I start merging to the project again, it starts deleting all specific project files that I reverted in the merge to the framework
[02:09] <fullermd> So your next best bet it to just cherrypick back the fixes, not do full merges.
[02:09] <Phoenixz> fullermd: yeah, that is VERY impractical....
[02:09] <Phoenixz> fullermd: would take up lots of extra hours, lots of human errors.. dont even want to think about it
[02:09] <Phoenixz> fullermd: isnt it possible to have a merge filter in place, that would only merge those things NOT in the filter?
[02:10] <Phoenixz> fullermd: so that it transparently will skip those directories that are specific to one project
[02:10] <Phoenixz> ?
[02:10] <fullermd> The short answer is "no"
[02:10] <Phoenixz> Thats not really the answer I was waiting for... :)
[02:11] <fullermd> Cherrypicking back the actual revs that fix stuff in the framework code is the rightest (or least-wrong) option in practice.
[02:11] <fullermd> It may lead to a few blips of spurious conflicts when you merge back, but that's manageable.
[02:12] <fullermd> Well, OK, there's the other answer, which is "use darcs"  ;p
[02:12] <Phoenixz> fullermd: THAT is a surpise answer... :)
[02:12] <Phoenixz> fullermd: and why not "Lets implement that in bzr"? :P
[02:13] <Phoenixz> fullermd: thing is, I got BZR control finally implemented in a development library here.. from the site I can do commits, with library version updates, etc... saves lots of time.. just re-wrote it from SVN.. would hate having to make another one for DARCS now :)
[02:13] <Phoenixz> and truth be told, I kinda like BZR :P
[02:13] <fullermd> Well, because in a fundamental-world-model sense, there are two classes of VCS's; there's darcs, and there's everyone else.  And this sort of thing (arbitrary subsets of revisions) is basic to the darcs worldview, and anathema to everyone else.
[02:14] <fullermd> I was being rather more facetious than serious   :p
[02:15] <Phoenixz> fullermd: hehehe.. okay, but what are my options here then? I dont want to have to work on 2 projects at the same time, testing for bugs in one, and then fixing them in another.. thats rather.. horrendous..
[02:17] <fullermd> Do it in the downstream and then cherrypick back just that one rev.
[02:17] <fullermd> (and then immediately re-merge it, to dispose of the potential conflict if necessary right away when it's simple)
[02:17] <Phoenixz> fullermd: eh, sorry, lots you.. downstream is... where? and cherrypick, how would I interpret that ?
[02:18] <fullermd> Downstream would be your app using the framework.
[02:18] <Phoenixz> fullermd: okay, but so.. how would I cherrypick back then?
[02:18] <fullermd> Cherrypicking is [in this case] the act of [pseudo-]merging back just a single rev.
[02:18] <fullermd> e.g., `bzr merge -c345 ../downstream`
[02:19] <fullermd> (where -c does NOT mean cherrypick)
[02:19] <Phoenixz> -c would be revision?
[02:20] <fullermd> -c means "change".  It's basically a shortcut: "-cX" is shorthand for "-rbefore:X..X"
[02:20] <fullermd> What actually makes it a cherrypick is that the ancestries you're merging aren't fully connected.  So bzr doesn't (can't) record an actual merge.
[02:21] <Phoenixz> could I do bzr merge -c345 346 348 for example?
[02:21] <fullermd> The 'merge' degenerates to being just a smart form of "diff | patch"
[02:22] <Phoenixz> fullermd: mmmmm, so basically, bzr branch on the framework side would not know that the changes came from, say, multiple changes on the project brnach?
[02:22] <fullermd> No.  You could do a series of merges (using --force to convince it to let you merge into an unclean WT), which may or may not work out well.
[02:22] <fullermd> Right.  It can't, unless you share all the history.  And you don't want that.
[02:24] <Phoenixz> fullermd: BZR is my "its complicated" on facebook at the moment.. :)
[02:25] <Phoenixz> So I guess I'll have to be cherrypicking then..
[02:25] <fullermd> Yeah.  "Real" cherrypicking is what you'd want in the ideal case anyway, so an approximation of it is the heir apparent.
[02:30] <Phoenixz> fullermd: okay, I'll start experimenting a bit to get the hang of it.. meanwhile, if I've been doing the whole merging back thing before, that wouldnt be a problem, right?
[02:30] <fullermd> Well, it means the whole history (up to the "latest" point anyway) of all your downstream projects is sitting around in the history of your framework.
[02:31] <Phoenixz> fullermd: so best would be to just start with a clean import again? to make sure that all history is gone?
[02:31] <fullermd> With all the history-size and sensitive-info complications that brings.
[02:31] <fullermd> Well, or just back up to before you started merging downstreams in.
[02:32] <fullermd> Depending on how much comes after that, either redoing them piecemeal or just splatting the current state over.
[02:33] <fullermd> Some care would need to be taken with any new files etc. to be sure they have appropriate identities, otherwise you set yourself up for more ugliness in the future.
[02:35] <Phoenixz> fullermd: By the way, upgraded to bzr 2.2 nightly build, same error...
[02:36] <Phoenixz> fullermd:
[02:36] <Phoenixz> bzr: ERROR: branch has no revision sven@fs-ex-20100714193341-nxxm4776w97sbaip
[02:36] <Phoenixz> bzr update --revision only works for a revision in the branch history
[02:36] <fullermd> What's the version/date of the build?
[02:40] <fullermd> Hm.  I think NEWS is cracked on exactly when the bugfix came in, but it was in April anyway.
[02:40] <spiv> We need to fix bzr to fetch the revisions of tags as well as the tip when you fetch a branch.
[02:40] <spiv> There's a bug about that.
[02:40] <fullermd> spiv: No, I'm pretty sure this is the "update -r blows chunks when given non-mainline rev"
[02:40] <spiv> Oh, ok.
[02:40] <fullermd> Which is mis-attributed in NEWS.
[02:41] <fullermd> Maybe.  It's hard to tell...
[02:42] <fullermd> The 2.2b1 tag doesn't seem to be in bzr.dev or bzr-2.2's ancestry.
[02:43] <Phoenixz> fullermd: one sec, running the export and frankly, my laptop is dying with workload, one sec.
[02:45] <Phoenixz> fullermd: Bazaar (bzr) 2.2.0dev1
[02:46] <Phoenixz> fullermd:  thats the bzr I found in ubuntu repos.. Im gussing I'll have to build this one for being way to new..
[02:47] <fullermd> That sounds oldish...   more recent would be 2.2b<something> or at least a higher dev#.
[02:49] <Phoenixz> fullermd: yeah, my guess too.. but that means building from source
[02:50] <fullermd> If you have the appropriate stuff (like pyrex) installed, that's pretty easy.
[02:50] <fullermd> You don't have to _install_ the bzr; you can just run it out of the source tree.
[02:50] <fullermd> (and actually, you don't strictly _need_ the pyrex or other build stuff even)
[02:54] <Phoenixz> fullermd: well, I'll think about it.. for now, I have a project to deliver first :)
[02:55] <fullermd> Oh, how dearly I'd love to not understand what you mean...
[07:26] <rom1> salut
[07:36]  * spiv does the install-ubuntu-on-new-laptop dance
[07:37] <lifeless> \o/
[07:46] <vila> spiv: woohoo ! specs ?
[07:47] <spiv> vila: "not 3.5 years old" is the important one ;)
[07:48] <spiv> Thinkpad T410 with a random selection of options ;)
[07:48] <vila> CPU, memory size, SSD/HD size ?
[07:49] <vila> screen size, weight
[07:49] <spiv> Yep, it has a CPU.
[07:49] <spiv> ;)
[07:50] <vila> jam is disgusted :)
[07:50] <spiv> i7-620M, 4GB RAM, 320GB HDD, 14", not as heavy as my previous.
[07:51] <spiv> To a large extent I really don't care about any of that.
[07:51] <vila> ha ha, no SSD then...
[07:51] <spiv> The main things I cared about were the VT extensions for happy kvm and, well, that's about it ;)
[07:51] <vila> but 4 threads... welcome to --parallel=fork heaven :)
[07:52] <spiv> I'm essentially satisfied with the computing power of my old laptop, it's just the lack of battery life and functioning keyboard that's the problem :)
[07:52] <vila> yeah, keyboard helps
[07:53] <spiv> I suspect it's nearly impossible to buy a laptop that's crummier than something 3.5 years old except perhaps by getting a netbook... and even then it's probably a near thing.
[07:54] <spiv> (A relatively cheap laptop from 3.5 years ago, too)
[07:55] <vila> spiv: don't forget to use tmpfs for /tmp and /var/tmp, AFAICS that's still not the default for maverick
[07:55] <spm> spiv: have you looked towards 2nd hand? the laptop I use for taking away is such; light, not too powerful; but good enough.
[07:56] <spiv> spm: not really, I'm trying to own less electronic crap rather than more ;)
[07:56] <spm> heh
[07:56] <spiv> spm: it's not a bad idea, but really after my previous laptop with 9-cell battery + separate keyboard this one will seem pretty light :)
[07:57] <spiv> No need to get myself used to unreasonable luxury...
[07:57] <spm> ha!
[07:58] <spm> fwiw, I got mine via recompute.com.au. I wouldn't say I'm entirely *thrilled* with their service (they delivered without the promised internal wireless, and convincing them of same was a pita), but not too shabby. dealt with worse.
[07:58] <spiv> ta!
[07:58] <spm> damn!  	IBM ThinkPad T43 Laptop $329!
[07:59] <spiv> Hee :)
[08:05] <jam> spiv: have a good night
[08:08] <spiv> jam: thanks :)
[08:22] <james_w> jam: https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/cuyo/maverick-201007212128/+merge/30582 https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/libsmbios/maverick-201007211814/+merge/30567 https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/cloud-init/maverick-201007211812/+merge/30566
[08:22] <james_w> jam: collisions detected overnight, possibly due to the change to diff
=== oubiwann-away is now known as oubiwann
=== bigjools-afk is now known as bigjools
=== beuno is now known as beuno-lunch
=== Pilky_ is now known as Pilky
=== beuno-lunch is now known as beuno
[18:33] <aj-dneg> hellos! i am using bzr-svn to push commits onto my company's giant svn repo, but i am getting an error when i try to push my changes now "ERROR: These branches have diverged."
[18:34] <aj-dneg> i suspect it's because there have been commits to the repo elsewhere that have bumped the revno or something?
[18:34] <jelmer> aj-dneg: there are changes on the same branch that you're pushing to
[18:34] <jelmer> aj-dneg: changes that are not present in the local tree that you're trying to push
[18:34] <aj-dneg> i'm the only one pushing to it though!
[18:34] <jelmer> aj-dneg: try running "bzr missing <url>"
[18:34] <aj-dneg> bzr missing svn://blablabla?
[18:35] <jelmer> yep
[18:35] <aj-dneg> oh f&£#, my bad
[18:35] <aj-dneg> i pushed it somewhere else and then did an svn mv from one location to another
[18:36] <aj-dneg> the revision i'm missing is "moved the code"
[18:36] <aj-dneg> however shall i fix this?
[18:37] <aj-dneg> i tried doing bzr merge but it just whinged about something...:
[18:37] <jelmer> you can either rebase your local tree onto the remote one ("bzr rebase <url>") or simply ignore the fact that extra revision is present remotely ("bzr push --overwrite <url>")
[18:38] <aj-dneg> hm, might try rebase
[18:38] <aj-dneg> what would you do? :)
[18:39] <aj-dneg> aw i couldn't rebase: different rich-root support
[18:39] <aj-dneg> same as if i try to merge
[18:40] <aj-dneg> ok --overwrite worked a treat, thanks
[18:41] <aj-dneg> anyone know how to save username/password for bzr svn?
=== Ursinha is now known as Ursinha-nom
[20:06] <dash> does the bzr-eclipse guy hang out here? :)
[20:08] <jelmer> dash: He is verterok
[20:09] <verterok> jelmer: hi :)
[20:09] <verterok> dash: hi
[20:09] <dash> verterok: first, thank you for making life with eclipse easier ;)
[20:09] <dash> verterok: any thoughts on what it'd take to make bzr work with the 'team synchronizing' feature?
[20:10] <verterok> dash: thanks :), sadly it's been a while since I got enough time to work on bzr-eclipse :(
[20:11] <verterok> dash: not offhand
[20:11] <verterok> dash: but I would take a look to the egit implementation (I read somewhere they just added support for it)
[20:12] <dash> sounds good
[20:12] <dash> thanks. :)
[20:13] <verterok> dash: or the mercurial plugin, don't know if the support 'team synchronizing'
=== Ursinha-nom is now known as Ursinha