[00:29] <keithy_> hmm I wont to install config manager on my laptop but I dont have gcc/develper tools loaded
[00:29] <keithy_> want*
[01:29] <timClicks> am attempting bzr pull --overwrite and am receiving
[01:29] <timClicks> bzr: ERROR: Cannot lock LockDir(lp-64843152:///~flavour/sahana/sahanapy-trunk/.bzr/branchlock): Transport operation not possible: readonly transport
[01:29] <timClicks> is there anything I can do on my end? it looks like something to do with launchpad
[01:29] <fullermd> DDTT(tm).
[01:30] <fullermd> You're doing that in a checkout of the branch on LP, to which you don't have write access, so writing to it fails.
[01:33] <versatiletech> I'm having issues with getting my linux user permissions right for someone on the outside to bzr push bzr+ssh:// in? Can someone point me to the right direction?
[01:34] <fullermd> Well, what's wrong with 'em?
[01:35] <fullermd> They need write into the branch, and its respository.
[01:35] <versatiletech> hmm
[01:35] <mkanat> In pre_change_branch_tip, what's the right way to get the email address of the committer? By parsing new_revid, or is there some better way?
[01:36] <versatiletech> fullermd: I guess the ssh user needs to be in the same group as the bzr folder's group correct?
[01:37] <fullermd> Well, that's one way to do it.  Another would be with world permissions.  Another possibility would be stepping outside the normal *nix permission system with some sort of ACL, if your system supports that.
[01:37] <fullermd> But group is the normal solution, yes.
[01:38] <versatiletech> right now the .bzr's group is proftp
[01:38] <versatiletech> does the user's primary group need to be proftp?
[01:38] <versatiletech> or can there secondary group be proftp?
[01:38] <fullermd> No, they just need to be in it.
[01:38] <versatiletech> cool
[01:38] <versatiletech> let me try that
[01:39] <fullermd> If you're on a system with SysV filesystem semantics, you probably want g+s on some of the directories.
[01:50] <keithy_> is there a way to checkout such that you get just the files no scm behavuior
[01:50] <keithy_> i.e checkout --lightweight
[01:50] <keithy_> but more a deploy
[01:50] <fullermd> You mean like export?
[01:51] <fullermd> (of course, with no scm behavior, you can't do things like "update" either)
[03:55] <MTecknology> bzr: ERROR: KnitPackRepository('lp-64843152:///~scripters/scripting/trunk/.bzr/repository')
[03:55] <MTecknology> is not compatible with CHKInventoryRepository('lp-64843152:///~mtecknology/scripting/server-scripts/.bzr/repository')
[03:55] <MTecknology> That's odd.. any ideas?
[03:59] <fullermd> One side is a pack-0.92 or the like, the other is 2a.
[04:00] <fullermd> Specifically, yours is 2a, and you're trying to move revs from that into the ~scripters one which isn't possible.
[04:03] <MTecknology> fullermd: any way to make that work?
[04:03] <fullermd> No.  Rich-root revs aren't compatible with poor-root repos.
[04:04] <fullermd> So your choices are (a) Upgrade the far side, or (b) Redo changes in a poor repo.
[04:04] <MTecknology> fullermd: I'm trying to push to a branch that doesn't exist
[04:05] <versatiletech> assuming I do bzr remove MYCONFIGFILE.ext --keep, then bzr commit && bzr push-and-update. If someone else does a bzr pull, will their MYCONFIGGILE.ext be erased?
[04:05] <fullermd> Mmm.  The error could be coming from trying to stack, I guess.
[04:05] <fullermd> versatiletech: Yes.
[04:06] <versatiletech> ouch
[04:06] <versatiletech> any other options?
[04:06] <fullermd> Not in-bzr, no.  A file's either extant in a rev or not.
[04:09] <versatiletech> I guess what I could do is tell everyone to backup their MYCONFIGFILE.ext, then I bzr remove MYCONFIGFILE.ext --keep from the central repo. Then bzr ignore MYCONFIGFILE.ext.
[04:09] <versatiletech> are bzr ignore's local?
[04:10] <versatiletech> or if somebody bzr pull's they'll get the new ignore that was committed to the central repo?
[04:10] <fullermd> Depends on whther the ignore file is versioned.
[04:10] <versatiletech> k
[04:10] <fullermd> Which it presumably is, if you're using the 'bzr ignore' command.
[04:10] <wgrant> (by default it is)
[04:11] <versatiletech> yeah I noticed that I couldn't ignore a versioned files
[04:11] <versatiletech> file*
[04:11] <versatiletech> Warning: the following files are version controlled and match your ignore pattern:
[04:11] <versatiletech> application/config/database.php
[04:11] <versatiletech> These files will continue to be version controlled unless you 'bzr remove' them.
[04:11] <fullermd> Oh, you can put it in just fine.
[04:11] <fullermd> bzr ignore just warns because the command doesn't DO anything.
[04:12] <versatiletech> so basically it doesn't truly ignore the file unless I do bzr remove
[04:13] <versatiletech> in other words if I make a change to database.php after doing bzr ignore to it, it will still be committed since it's versioned
[04:13] <fullermd> The only thing that 'ignored' means is that 'add' won't add it when it walks across it, and 'status' won't show it as 'unknown'.
[04:13] <fullermd> It doesn't affect anything else.
[04:14] <versatiletech> ah
[04:14] <versatiletech> k I got it now
[04:27] <MTecknology> fullermd: any idea about this? http://paste.ubuntu.com/362361/
[04:27] <MTecknology> 2 servers give me that; 2 servers work correctly
[04:28] <fullermd> It means you don't have your public key setup right.
[04:28] <MTecknology> none of the root users on any server have ssh keys published to launchpad
[04:29] <MTecknology> I only want them to pull down the content - should need authentication..
[04:29] <fullermd> If they've been lp-login'd, they'll always need authentication.
[04:30] <MTecknology> I didn't think I did.. if they did how can I undo that?
[04:30] <MTecknology> there's no /root/.bzr*
[04:30] <fullermd> Going through sudo and using your original user's ~?
[04:31] <MTecknology> OOPS
[04:32] <MTecknology> fullermd: thanks :D
[04:32]  * fullermd is a cheenius   8-}
[04:33] <MTecknology> ya, you are
[06:02] <ChrisMorgan> I've got bzr-gtk installed on my Ubuntu system but Nautilus integration isn't happening; the emblems are available but overlaying of files isn't happening.
[06:02] <ChrisMorgan> Any idea why or what I should do to get it working?
[08:21] <johnf> has 2.0.4 not hit pqm?
[08:24] <fullermd> PQM committed "Release 2.0.4 final" on Thursday...
[08:24] <johnf> my bad. Wasn't looking at the 2.0 branch
[08:33] <poolie> hello all
[08:35] <poolie> igc, hi?
[09:29] <james_w> good morning sprinters
[09:47] <poolie> hello james_w
[09:48] <poolie> are you home now?
[09:54] <james_w> no, I'm still in NZ
[10:01] <hydratenaturally> i did something stupid...
[10:02] <ChrisMorgan> Does anyone know how I can get nautilus integration via bzr-gtk working?
[10:02] <hydratenaturally> using a hosted svn solution, i checked out the repo using bzr-svn, made some bzr --local committ's, went to make a big upstream committ, and when i did a bzr update it removed all my locally committed changes
[10:04] <ChrisMorgan> hydratenaturally: I think that's one of the times for that famous saying, "Whoops."
[10:04] <hydratenaturally> yeah...
[10:04] <hydratenaturally> well, i'm just lacking the knowledge of bzr to go back and find my locally comitted changes
[10:04] <hydratenaturally> i imagine a few commands here and there saves my life
[10:05] <hydratenaturally> using debian or ubuntu by chance chris ? https://bugs.launchpad.net/ubuntu/+source/bzr-gtk/+bug/287988
[10:05] <fullermd> Update didn't remove your locally committed changes, it pivoted them to be a pending merge.
[10:06] <hydratenaturally> mm ok
[10:06] <hydratenaturally> sigh so where is this pending merge
[10:06] <fullermd> Check status.
[10:07] <ChrisMorgan> hydratenaturally: ubuntu, amd64
[10:07] <hydratenaturally> status says nothing
[10:07] <fullermd> Then you did a revert or some such since the update.
[10:07] <ChrisMorgan> hydratenaturally: the thing is it's not working.  It's meant to be in there (they've even got screenshots of it) but the emblems are not being overlaid as they should
[10:08] <ChrisMorgan> hydratenaturally: `bzr log`?
[10:08] <fullermd> Log by itself won't help after the pivot, the revs aren't in that branch's history anymore.
[10:08] <ChrisMorgan> You may want just the last N revisions though, add -l20 for the last 20
[10:08] <hydratenaturally> ugh i promise i didn't revert, here is a log of what happened http://pastie.org/793276
[10:09] <ChrisMorgan> Ooh, another chris!  ;-)
[10:10] <hydratenaturally> yeah, is there a way of reviewing only your --local committ's ?
[10:10] <fullermd> Well, then either (a) there weren't any local commits in that branch, or (b) some weird bug exists hidden in bzr that nobody else has ever seen.
[10:10]  * fullermd isn't better on (b).
[10:10] <fullermd> Or betting, either.
[10:11] <fullermd> You can use 'heads' (in bzrtools) to see if there are any dead heads in the repo.  Lost local commits would show up there.
[10:11] <hydratenaturally> history | grep ci | grep local shows me making local committs, i maybe dellusional...
[10:12] <fullermd> Or you may be making them in different checkouts.
[10:12] <hydratenaturally> checked that
[10:13] <hydratenaturally> heads doesn't say much, just something about my last upstream committ
[10:14] <fullermd> You probably need heads --dead-only
[10:14] <fullermd> I don't think it lists dead heads by default.
[10:14] <hydratenaturally> still nothing
[10:15] <fullermd> Is the repo shared with other branches/checkouts?
[10:15] <hydratenaturally> nah, very vanilla
[10:15] <hydratenaturally> remotely hosted on beanstalk
[10:15] <hydratenaturally> did initial import with svn
[10:15] <fullermd> Not the svn repo, your local bzr repo.
[10:16] <hydratenaturally> nope
[10:16] <hydratenaturally> no local branching or checkouts
[10:16] <fullermd> Then there aren't any commits in the repo that aren't in the history in svn.
[10:17] <hydratenaturally> bzr log shows none
[10:19] <hydratenaturally> actually they're off by 1
[10:22] <ChrisMorgan> Well, I got bzr/nautilus integration working.  sudo ln -s /usr/share/pyshared/bzrlib/plugins/gtk/nautilus-bzr.py /usr/lib/nautilus/extensions-2.0/python/ and then restart nautilus
[10:27] <hydratenaturally> man this sucks....
[10:30] <hydratenaturally> um where does bzr store committs with --local ?
[10:30] <fullermd> The same place it stores any other revisions.
[10:30] <hydratenaturally> how would i go about pursing that, to say look for one of these deleted files
[10:32] <fullermd> Available evidence suggests there aren't any there, which means (since it takes heroic measures to remove things from a repo) there never were any.
[10:32] <fullermd> If they don't show up in heads --all, they're not heads.  The only way they could not be heads would be to be in the ancestry of a branch in the repo.
[10:33] <fullermd> Since you say there's only the one [pseudo-]branch (that checkout), it means either the revs aren't there (and so never were), or they're in the ancestry of that checkout (which is the same as the svn repo's).
[10:34] <fullermd> Of course, it's _possible_ there's some bug somewhere along the line that's preventing them from showing up, and also prevented them from being left as pending merges in that update.
[10:35] <fullermd> But it would be the first hint I've heard of such, after all the features have been around a long time, and I wouldn't know where to start looking for it.
[10:35] <hydratenaturally> yeah i doubt it's a bug, probably something stupid i did
[10:35] <fullermd> Well, start looking at the assumptions.
[10:36] <fullermd> Check out info -v, for instance.
[10:36] <fullermd> If it's not using a shared repo, there's no way some other branch could be interfering with the heads detection.  If it is, see what other branches are in it.  That can eliminate one question, one way or another.
[10:37] <fullermd> See how many revs it lists being in the branch history, and how many are in the repository.  Being from svn, it's probably a linear history, so maybe they should match up?  Not sure how strong an indicator that might be.
[10:37] <hydratenaturally> k odd, bzr info -v shows repository: 36 revisions
[10:37] <hydratenaturally> but bzr log only shows me 30 revisions
[10:37] <fullermd> What's the first line of info say?
[10:37] <hydratenaturally> http://pastie.org/793293
[10:38] <fullermd> 'k, take your right hand, and hold it about 2 feet away from your left cheek.
[10:38] <hydratenaturally> yeah i'm stupid i get it
[10:39] <fullermd> 8-}
[10:39] <fullermd> Then look at how 'heads' lists two heads, with one of them flagged as the tip of the branch (checkout), and the other listed as dead.
[10:40] <fullermd> What version of bzr are you running, BTW?  rich-root-pack suggests pre-2.0; an upgrade may be in order (not that it has any bearing on this issue; just a general query)
[10:41] <hydratenaturally> this bug seems interesting
[10:41] <hydratenaturally> https://bugs.launchpad.net/bzr/+bug/395514
[10:41] <hydratenaturally> debian 2.0.3-1
[10:41] <hydratenaturally> bzr-svn 1.0.0-1
[10:41] <hydratenaturally> debian = bzr
[10:41] <fullermd> Hm.  Maybe Debian makes local changes, or you had an older version when you made the checkout.
[10:41] <fullermd> Anyway.
[10:42] <fullermd> So that dead head is presumably the head of your local commits.
[10:42] <hydratenaturally> ok, makes sense
[10:42] <hydratenaturally> my bzr knowledge is lacking on how to merge those changes into my "working" head
[10:42] <fullermd> So you can use 'merge' to setup a merge of them.
[10:43] <fullermd> (of course, a lot of the merge info won't get into svn; unavoidable.  But the changes will, crumbed into one rev)
[10:43] <fullermd> `bzr merge -rchris@camus-20100125091843-zdk7x8gxpdeq8s4l .`
[10:43] <fullermd> (the trailing '.' is important)
[10:43] <fullermd> Then the usual check/commit.
[10:44] <hydratenaturally> ah ok didn't see revision-id there in heads -all
[10:45] <hydratenaturally> chris@camus:~/projects/fashionbone/bzr-beanstalk$ bzr merge -rchris@camus-20100125091843-zdk7x8gxpdeq8s4l .
[10:45] <hydratenaturally> bzr: ERROR: No namespace registered for string: u'chris@camus-20100125091843-zdk7x8gxpdeq8s4l'
[10:45] <hydratenaturally> just wtf
[10:45] <poolie> hydratenaturally: you need -r revid:christ@.... i think
[10:45] <fullermd> OK, now I think you're lying about your bzr version too   :p
[10:46] <hydratenaturally> chris@camus:~/projects/fashionbone/bzr-beanstalk$ bzr version
[10:46] <hydratenaturally> Bazaar (bzr) 2.0.3
[10:46] <fullermd> OK, maybe not.  I thought the DWIM was in 2.0....
[10:46] <fullermd> But it looks like 2.1.  So what poolie said.
[10:51] <hydratenaturally> can't get the right syntax
[10:51] <hydratenaturally> chris@camus:id
[10:51] <hydratenaturally> vice versa
[10:51] <fullermd> No, -rrevid:chris@camus-20100125091843-zdk7x8gxpdeq8s4l
[10:52] <fullermd> revid: tells bzr it's getting a revision id, then the string.
[10:52] <hydratenaturally> ah
[10:53] <hydratenaturally> ah it worked, awesome
[10:53] <hydratenaturally> thanks for all the help guys, you save me oh so much pain
[10:53] <fullermd> Don't forget to commit the merge, before you forget it's there and mix new work in with it.
[10:54] <hydratenaturally> heh, course, i just rsync'd the whole dir to my raid1 "just in case"
[10:54] <hydratenaturally> i'm so overtired at this point that....
[11:02] <hydratenaturally> fullermd: thanks again
[11:02] <fullermd> np
[11:02] <hydratenaturally> i was about to take 2 xanax and have a drink
[11:02] <hydratenaturally> i hear they call it the "jackson"
[11:03]  * fullermd . o O ( Isn't that pretty much the same thing as using SVN anyway? ) O o .
[11:03] <hydratenaturally> ahahahah
[11:04] <hydratenaturally> i should tack on 10/hour to my rate to use subversion
[11:04] <hydratenaturally> and 25/hour for cvs
[11:05] <fullermd> How much for Clearcase?
[11:06] <hydratenaturally> oh jesus
[11:06] <hydratenaturally> free healthcare
[11:06] <hydratenaturally> forever
[11:28] <doctormo> What's the best way to diagnose bzrlib being used in a thread... I can't decide if it's just taking a while to get a transport, or if it's stalled dead.
[11:35] <doctormo> I think it's the get transports that are freezing out
[11:35] <doctormo> Man bzrlib is way worse than launchpadlib. at least lp is ok so long as your lp object is in the same thread. bzr just dies if is so much as sees threading being imported.
[11:36] <doctormo> Worse, it dies by freezing without errors. locking up, charming.
[11:42] <Raim> is there a short URL spec to refer to the parent/push branch from the command line?
[11:46] <Kinnison> what are you trying to achieve?
[11:48] <fullermd> :parent, :push
[12:09] <Kinnison> are those urlspecs?
[12:09] <Kinnison> coo
[12:10] <lifeless> doctormo: this is patently false as we use threading ourselves
[12:10] <fullermd> Not urlspecs, no.  Builtin aliases.
[12:10] <lifeless> doctormo: do you have a ssce ?
[12:11] <lifeless> sorry, sscce
[12:35] <doctormo> lifeless: No, just rotten luck.
[12:37] <lifeless> if you have a deadlock, gdb can be great at debugging it
[12:37] <lifeless> you may have found a python bug, for instance.
[12:37] <bialix> heya bzr!
[12:39] <doctormo> lifeless: Possible, I'll have to look into it using gdb.
[12:41] <doctormo> Time for bed now though...
[12:41] <doctormo> thanks for your help
[13:10] <epschern> can i set up tortoise bazaar in a way so someone with bzr 1.3.1 can access it? (think i had no voice when i asked before)
[13:13] <blenderkid> hi. I did a mistake with bzr revert. I reverted all files instead of just one file. now the other files are lost. Is there a way to revert a revert?
[13:14] <beuno> blenderkid, bzr makes a backup of the files when reverting
[13:15] <beuno> try an ls -la in the dir
[13:15] <blenderkid> a file with a ~1~ ?
[13:15] <beuno> yes
[13:15] <blenderkid> ahh good *puh*
[13:16] <blenderkid> Do I just need to rename it?
[13:16] <beuno> yeap
[13:16] <blenderkid> thank you so much :)
[13:16] <MTecknology> blenderkid: I think that little feature has probably been able to save countless hair pullings
[13:17] <blenderkid> :D
[13:24] <epschern> hm, can i somehow downgrade my repository format?
[13:25] <fullermd> Depending on the exact pair of formats.  'down' and 'up' are arbitrary directions.
[13:28] <epschern> well, the server has only 1.3.1 and sysadmin refused to upgrade... but our windows machines have newest tortoise bazaar
[13:28] <epschern> i found now i can set the format on init... but don't want to lose all my commits so far
[13:28] <fullermd> You can 'update' to rich-root-pack, which 1.3.1 can read.
[13:29] <fullermd> Presumably, your current stuff is in 2a, which you can't move to a non-rich-root format.  But r-r-p will take you back to 1.0.
[13:31] <bialix> vila, beuno: here?
[13:32] <beuno> bialix, hey
[13:32] <bialix> q about upload
[13:33] <bialix> beuno: any ideas what's wrong: http://pastebin.com/d5aaaadc0
[13:33]  * beuno looks
[13:35] <beuno> bialix, no, there seems to be an error with the path somehow
[13:36] <epschern> fullermd: i tried it but it failed: http://paste.debian.net/57608/
[13:36] <beuno> does the branch have anything funky?
[13:36] <bialix> I guess no
[13:37] <beuno> bialix, maybe you could try trunk?
[13:37] <bialix> trunk of the bzr-upload?
[13:37] <bialix> ok, I'll try
[13:38] <fullermd> epschern: Mmph.  Stupid upgrade.
[13:38] <fullermd> epschern: You can work around it by 'init'ing a new branch in rich-root-pack format, then 'pull'ing from your 2a branch.
[13:52] <bialix> beuno: upload trunk works for me
[13:53] <bialix> beuno, vila: can you release it as 1.0.1?
[13:53] <bialix> current version bundled into windows installer seems to be broken
[13:54] <bialix> and it seems you know about it
[13:54] <beuno> bialix, sure, I'll chat with vila about releasing soon
[13:54] <bialix> ok
[13:59] <epschern> fullermd: thanks a lot, that worked
[14:00] <epschern> now i still hope cent-os or whatever the server has installed will upgrade their bzr version at some point so there won't be the deprecation message each time :)
[14:01] <fullermd> Well, you can push and pull back and forth.  So you could use 2a in your branch on the machine with non-ancient bzr version, and just use r-r-p on the old box.
[14:02] <epschern> i see
[14:02] <epschern> might do that once i'm more used to it (just had to switch over from git)
[14:14] <jelmer> poolie, lifeless, vila, jam: http://wiki.bazaar.canonical.com/BzrForeignBranches/Infrastructure
[14:28] <vila> bialix: bzr-upload is supposed to talk to a server where *bzr* is not installed, trying to make it talk to a bzr *smart* server is... interesting but they have opposite aims: bzr-upload want to provide a remote file system abstraction, the smart server try to get away from the remote file system abstraction
[14:28] <bialix> ыщ Ш ырщгдв гыу ыаез штыеуфв,
[14:28] <bialix> so I should use sftp instead?
[14:29] <bialix> hi vila
[14:29] <vila> bialix: sftp sound better
[14:29] <vila> bialix: hi :D
[14:30] <bialix> ok, I understand you about abstraction
[14:30] <bialix> maybe you need to puth this remark to upload's help
[14:30] <bialix> *put
[15:18] <lifeless> poolie: http://kitenet.net/~joey/blog/entry/a_clean_BTS_is_a_sign_of_a_sick_mind/
[15:30] <lifeless> poolie: http://bethesignal.org/blog/2009/12/31/this-is-not-a-new-years-resolution/
[15:43] <jelmer> poolie, https://code.edge.launchpad.net/~jelmer/tribunal/view-subunit/+merge/18006
[16:01] <radoe_> Where should I report broken links in the online version of the user guide?
[16:03] <rubbs> radoe_: make a bug report on lp, or mail the mailing list
[16:05] <radoe> rubbs: report it simply against bzr or is there something  better suited for docs?
[16:05] <rubbs> ah, report against bzr, but put 'doc' in the tags list at the bottom. Someone should take it up soon.
[16:06] <radoe> rubbs: thx.
[16:06] <rubbs> np
[16:25] <micahg> with bzr-svn do I have to worry about branches not being from the same source when merging?
[17:27] <micahg> with bzr-svn do I have to worry about branches not being from the same source when merging?
[17:28] <maxb> micahg: The question is a little vague, could you clarify?
[17:28] <micahg> I want to have a production and a devel branch in svn and import them both locally with bzr and push to svn with bzr svn
[17:28] <micahg> I was wondering if they need a common ancestor to merge
[17:28] <micahg> in bzr
[17:31] <micahg> maxb: is that any clearer?
[17:31] <maxb> They do need a common ancestor, but bzr-svn should deterministically import the common history i.e. it is _supposed_ to just work.
[17:34] <micahg> maxb: if I branch the dev code in bzr and then bzr-svn push to the prod branch, will that take care of the common ancestry
[17:35] <maxb> I think that bzr-svn will use various bzr* svn properties to record this such that bzr-svn on another computer can do the right thing
[17:36] <jelmer> yes, it will
[18:01] <poolie> jam: https://bugs.launchpad.net/bugs/512418
[20:08] <malibu> Hi there.. can anyone tell me how to see previous file versions in bazaar explorer?
[20:11] <malibu> I'm selecting the file in the tree pane but can't figure out how to see the versions
[20:15] <rubbs> malibu: ok, this may not be the only way, but I found a way to do it.
[20:16] <malibu> cool, thanks
[20:16] <rubbs> click on the browse button and it opens up a "file browser" You can then put a revision in the upper right corner
[20:17] <rubbs> that should change it to the revision and the files should then open as that revision...
[20:17] <malibu> ok mine opens up with WT:, which I suppose stands for working tree..
[20:18] <rubbs> correct
[20:18] <malibu> ok very cool.. thanks!
[20:18] <rubbs> you can replace that with any revision spec. So like to get to the one just before you can put "-1" in
[20:18] <malibu> ahh
[20:19] <malibu> Still I wonder if there is a way to get a list of every revision for a file..
[20:19] <rubbs> oh you mean like annotate?
[20:19] <malibu> what is annotate?
[20:20] <malibu> Sorry I'm a bit of a newB
[20:22] <rubbs> np,
[20:22] <rubbs> annotate will open the file and give you the revision that each line was changed last on
[20:22] <rubbs> or do you mean just the lastest revision that file was changed?
[20:23] <malibu> Well what I would like to see is a list of revisions that the file was changed on
[20:23] <rubbs> ah.
[20:23] <NfNitLoop> 'bzr log <filename>'.   Not sure how to do that in the GUI you're using.
[20:24] <rubbs> so if fileA was changed on revision 2, 5, and 7 then you want to see 2, 5, 7
[20:24] <rubbs> right?
[20:24] <malibu> yes
[20:24] <NfNitLoop> maybe right-click on the file?  IS there a "log" option in the context menu?
[20:24]  * NfNitLoop will brb, fixing IRC daemon.
[20:24] <rubbs> malibu: ok, easy.
[20:24] <malibu> Right clicking on the file does not do anything, unfortunately
[20:25] <rubbs> malibu: go browse then right click on file and hit "show log"
[20:25] <malibu> ahh.. must be in browse
[20:25] <malibu> I was trying to right click on the tree node for the file in the main window
[20:26] <malibu> I get error  bzr+ssh://.... is not a local path
[20:26] <rubbs> yeah, I have done that before. The reason he doesn't do that is the work that is needed in the browse window can be slow, so he didn't us it in that main view, because it could make the whole thing slow
[20:26] <rubbs> this way if you need some of that history viewing, you just hit browse, but don't have all the slow-downs by default
[20:27] <rubbs> the manage button opens an actaul file browser to the working tree
[20:28] <NfNitLoop> NOW WITH MOAR BEEF.
[20:28] <NfNitLoop> :p
[20:30] <malibu> OK well I'm not sure if it will work for me..
[20:30] <malibu> I get an error
[22:25] <Kilroo> Hmm. Does a bound stacked branch actually even mean anything?
[22:32] <thumper> Kilroo: I don't think so
[22:33] <thumper> Kilroo: although I guess you could have a light weight checkout of a stacked branch
[22:33] <Kilroo> I'm guessing the command I left running at work won't accomplish much then...
[22:33] <thumper> Kilroo: but I don't think you can commit to that due to a known bug
[22:33] <Kilroo> I'm trying to find a workaround for something
[22:33] <thumper> which something?
[22:33] <thumper> and where are you using stacking?
[22:35] <Kilroo> Well, what I have set up (albeit not thoroughly tested) for one of the subversion repositories I need to work with is a treeless repository with one branch bound to the subversion repo, feature branches as needed, and a lightweight checkout elsewhere that I can switch around among them. Nothing stacked there, at least not so far.
[22:36] <Kilroo> Unfortunately I can't do that with the another subversion repo I need to work with because revision 30 makes bzr run out of memory.
[22:37]  * bialix looking for igc
[22:39] <Kilroo> The command I left running when I departed from work today (which makes less and less sense to me the more I think about it) was a branch --bind --stacked from an svn checkout of the repository in question to a branch in a treeless repository.
[22:40] <mwhudson> bound and stacked are basically orthogonal
[22:40] <bialix> Kilroo: looks very funny
[22:41] <Kilroo> I think what I was trying to get out of it almost makes sense...but not quite...
[22:42] <bialix> mwhudson: does our beloved core devs sprinting again?
[22:42] <mwhudson> bialix: yes, in france this time
[22:42] <bialix> nice
[22:43] <bialix> I suppose igc is not there
[22:44] <mwhudson> bialix: right
[22:45] <mwhudson> he got the ok from his dr to travel, but decided not to go this time
[22:45] <Kilroo> What the heck would that do if it did make sense, come to think of it? Make a local branch from the subversion repo that would require a connection to it to do anything, have to be rebased to it any time it changed, and automatically commit to subversion when I committed locally?
[22:45] <Kilroo> This is making my head hurt. I think I'm being ridiculous.
[22:46] <bialix> mwhudson: thanks for the info. I have some q for him about explorer and translations. will hang around some time tonight
[22:46] <Kilroo> Stupid revision where the whole blasted site including graphics and pdfs and logs and probably freaking archive files gets added all at once.
[22:46] <mwhudson> bialix: yeah, i think he'll be on in a bit
[22:47]  * bialix nods
[22:47] <bialix> thanks
[22:48] <mwhudson> bialix: oh
[22:48] <mwhudson> bialix: except it's australia day today
[22:48] <mwhudson> so he's probably not going to be around :/
[22:48] <bialix> rats
[22:49] <bialix> australia go forward!
[22:50]  * bialix likes to think somewhere is summer right now, while outside his home is -25 celsius degrees
[23:12] <Kamping_Kaiser> woo, public holidays :)
[23:16] <NfNitLoop> Just had a loooong discussion w/ coworkers about branching/merging/SVNfail.
[23:23] <NfNitLoop> (rather intelligent) coworker was asking how large companies handle large numbers of branches.
[23:23] <NfNitLoop> I said hopefully not via svn. :p
[23:28] <Kilroo> Heh.
[23:28] <Kilroo> You know what's worse than svn?
[23:29] <idnar> haha
[23:29] <Kilroo> svn where instead of having a repo for the project and, say, a production branch and a development branch...you have two repos. One for production and the other for development. With everything at the repository root so you can't branch from it either.
[23:30] <Kilroo> And at least one revision in the repository that's so big bzr runs out of memory trying to look at it, so you can't even get local branches working.
[23:33] <NfNitLoop> oh god, yeah, you mentioned the prod/dev repos the other day.
[23:33] <NfNitLoop> That's some special kind of fail.
[23:33] <NfNitLoop> We actually do things mostly sanely around here.
[23:34] <NfNitLoop> we've got a 4.0 branch (old)   a 5.0 branch (current stable) and a 6.0 (dev) branch.
[23:34] <NfNitLoop> We do merges forward (->) most of the time.
[23:34] <Kilroo> The one thing to be said in its favor is that we have the revision history and who committed what, which we didn't have with plain ftp.
[23:34] <NfNitLoop> but every now and then someone does something that makes svn merging go all wonky.
[23:35] <NfNitLoop> like, not merge from the root of the project.
[23:35] <NfNitLoop> Or manually revert a change.
[23:35] <Kilroo> Unfortunately the people who set it up apparently didn't think beyond stacking that on top of the ftp approach.
[23:35] <Kilroo> And I seem to be the only person who ever uses commit messages.
[23:35] <NfNitLoop> Heh.
[23:35] <NfNitLoop> I'll say it again -- look for new work. :p
[23:36] <Kilroo> I -want- to fix it.
[23:37] <Kilroo> I think I actually have them convinced that it's worth it to let me take a break from developing new features to work on improving HOW we develop. Unfortunately I think I'm going to have to finish the two months-overdue database projects in my queue first.
[23:39] <Kilroo> And because of the braindead way we have svn set up on the things that are using it now, switching to using it in a reasonable way is going to be as much of a hassle as switching to it in the first place was.
[23:39] <Kilroo> And since I can't pull in the existing history using bzr because of the giant revisions, we may have to lose all the existing history instead of just half of it.
[23:40] <NfNitLoop> Why would you have to lose history?
[23:41] <NfNitLoop> would you be ditching SVN?
[23:41] <Kilroo> I wish...no, there's two things to deal with.
[23:43] <Kilroo> One, with development and production having thus far been separate repositories, I'm not sure there is any sane way to convert them into branches that can be treated like branches without pretty much ditching the history from one of them.
[23:44] <Kilroo> Specifically, make production into the trunk, branch from it for development, paste development over top of it and commit all of those changes as "fixing this harebrained separate repositories business."
[23:45] <Kilroo> The other problem is that the linux administrator seems to think we can migrate everything without either his intervention or root access to either the old repositories or where the new ones are going.
[23:45] <NfNitLoop> should be able to as long as you have write access.
[23:46] <Kilroo> As far as I've been able to determine, svn doesn't seem provide any means for performing the migration with those limitations, though.
[23:46] <NfNitLoop> though you might need him to shut down the svnserv or whatever it's called, if that's how you're accessing it.
[23:46] <NfNitLoop> anyway.
[23:46] <NfNitLoop> This isn't #svn. :p
[23:46] <Kilroo> At least, nothing I tried seemed to be working. However, branching using bzr-svn and then pushing to the new repository worked a treat.
[23:46] <mkanat> Kilroo: So it's fastimport that's running out of memory, here, that you're talking about?
[23:47] <Kilroo> mkanat: No, it's bzr-svn.
[23:47] <mkanat> Kilroo: Oh. Have you tried bzr-fastimport?
[23:48] <Kilroo> mkanat: currently I can't make any use of a solution that does not leave me capable of committing back to the current svn repository.
[23:48] <mkanat> Ah.
[23:49] <Kilroo> Yeah, fun stuff.