[00:59] <thumper> switch hurts with object files
[00:59] <thumper> perhaps switch should take into account ignored files (like .o)
[01:24] <lifeless> thumper: ack
[01:24] <lifeless> thumper: bites me all the freaking time
[01:44] <thumper> lifeless: we should come up with a plan
[02:09] <lifeless> thumper: needs  amerge conflict handler/resolver
[02:10] <mtaylor> lifeless: debian/changelog conflict handler/resolver!!!! :)
[02:13] <lifeless> mtaylor: doneish
[02:14] <lifeless> mtaylor: see the recently added merge hook
[02:15] <mtaylor> lifeless: w00t
[02:18] <keithy> I cant add files in a directory has 2.0 changed
[02:18] <keithy> are .cs files ignored by default?
[02:21] <keithy> hmm
[02:31] <RAOF> keithy: No, .cs files aren't ignored by default.  What are you trying to do and what is bzr doing instead?
[02:32] <keithy> ok..
[02:32] <keithy> I have a directory called updates
[02:32] <keithy> and when I do
[02:32] <keithy> bzr add updates/
[02:33] <keithy> and bzr status reports unkown:
[02:34] <keithy> so even basic stuff is defeating me
[02:34] <RAOF> Well, it works here.
[02:35] <RAOF> Can you pastebin the full terminal output of what you're doing and what bzr says in reply?
[02:35] <keithy> k
[02:35] <keithy> do you have a pastebin?
[02:36]  * igc lunch
[02:38] <keithy> keithy pasted "Bzr" at http://paste.lisp.org/display/93674
[02:38] <RAOF> paste.ubuntu.com works.
[02:40] <RAOF> keithy: Have you actually run “bzr add updates/”?  I don't see that in your terminal log, and that works for me.
[02:40] <keithy> yes
[02:40] <keithy> it does nothing
[02:41] <keithy> and there are 300 files in there that I expected to be added
[02:42] <RAOF> I guess another option would be “bzr add updates/*”, but I'm not sure why it hasn't worked already.
[02:43] <keithy> no that didnt work weither
[02:45] <keithy> ok I started again
[02:45] <keithy> it worked this time
[02:45] <RAOF> Heh.
[02:45] <RAOF> I wonder what was wrong, though.
[02:56] <meoblast> i pulled from another repo into mine and got http://sortedbits.ath.cx/bzr/nitrobot.bzr is permanently redirected to http://sortedbits.ath.cx/bzr/nitrobot.bzr/
[02:57] <meoblast> is that a problem?
[02:57] <meoblast> and should i be using merge instead?
[02:57] <AfC> Not a problem
[02:57] <meoblast> i'm trying to bring in someone's commit from his tree
[02:57] <meoblast> into the main tree
[02:57] <AfC> It's just saying you didn't have a trailing '/'
[02:57] <meoblast> i did have a trailing / but ok
[02:57] <AfC> [oh]
[02:58] <meoblast> but i suppose that's not a problem
[02:58] <AfC> no
[02:58] <meoblast> is pull the correct function to use to bring commits from someone else's branch into the main branch?
[03:00] <meoblast> merge doesn't do the job
[03:00] <meoblast> my commit log looks like this if i do, 1, 2, 3,  4, 5, 6, 7, 1, 2, 3 ,4 ,5 ,6 ,7 ,8
[03:02] <mwhudson> meoblast: merge is for combining lines of development, yes
[03:02] <meoblast> mwhudson: so why does it duplicate commits 1 - 7?
[03:03] <mwhudson> meoblast: it doesn't usually...
[03:03] <meoblast> mwhudson: ok, fixed
[03:04] <meoblast> when merging, do modified files in the merge come up as "modified:" as well?
[03:08] <mwhudson> meoblast: yes
[03:10] <meoblast> ok, thanks
[03:51] <mwhudson> lifeless: can i object mildly to bzrlib.tests monkeypatching traceback?
[04:06] <lifeless> mwhudson: you can object to traceback being brokeb.
[09:08]  * igc dinner
[11:36] <Ddorda> hey, Im trying to make a new branch, but for some reasons it says I don't have pernissions for that
[11:37] <Ddorda> Ive done bzr init; bzr add; bzr push lp:~ddorda/gezer/po
[11:38] <Ddorda> $ bzr push lp:~ddorda/gezer/po
[11:38] <Ddorda> Permission denied (publickey).
[11:38] <Ddorda> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[12:51] <michaelis> Hi. Is there any way to show swedish letters in bzr-explorer in windows. Or at least space character. As it is now there's a % sign and some number afterwards.
[12:57] <michaelis> Anyone?
[12:57] <keithy> ahh! I made it
[12:57] <keithy> ok...
[12:57] <keithy> its taken me so long to get here I cant remember what my question was
[12:57] <keithy> oh yes
[12:58] <keithy> is there an automatic directory contents tracking feature yey
[12:58] <keithy> yet
[12:58] <keithy> so you can add a directory and all its contents
[12:58] <keithy> non-manually
[12:58] <keithy> bzr add-and-track-contents somedirectorywherepeopleputstuff
[12:59] <michaelis> Why does bzr-explorer in win xp show %20 instead of a space character?
[13:04] <keithy> it looks like add doesnt have this option arg
[13:06] <mzz> keithy: err, using what tool? "bzr add directory" works for me...
[13:06] <mzz> I must be misunderstanding your question
[13:06] <mzz> bzr add --no-recurse directory for just the directory
[13:09] <keithy> but what if someone adds a file after you have done bzr add directory/
[13:09] <keithy> it is not managed is it
[13:11] <maxb> No, and this is intentional
[14:21] <NET||abuse> hey guys.
[14:21] <NET||abuse> just trying to add files to a repo on a webserver, so i can download the site through bzr.
[14:22] <NET||abuse> i am on the ssh root
[14:22] <NET||abuse> on the ssh shell as the website owners user, not root, sorry
[14:22] <NET||abuse> i have a web/ dir and a bzrsrc diri i've made
[14:22] <NET||abuse> i did bzr init on the bzrsrc
[14:23] <NET||abuse> then i copy in all the files under web
[14:23] <NET||abuse> then bzr add *
[14:23] <NET||abuse> then i try to bzr ci      it rolls through tons and eventually gets to a pdf, and hangs.
[14:23] <mzz> if anything in there is huge it may just be slow
[14:23] <NET||abuse> i can ctrl+c outa the commit action, but of course i'm scared that'll ruin something.
[14:24] <NET||abuse> it's only 5.4MB
[14:24] <NET||abuse> just sitting there.
[14:24] <mzz> fishy
[14:24] <NET||abuse> how can i debug this/
[14:24] <NET||abuse> ?
[14:25] <mzz> I'd consider strace-ing the process to see what it's doing
[14:25] <NET||abuse> strace-ing?
[14:25] <mzz> assuming that server runs linux
[14:26] <mzz> from your description it sounds like you're doing something quite normal and the only reason I can think of for a hang would be disk io being slow for some reason
[14:26] <NET||abuse> it's ubuntu dapper.
[14:26] <NET||abuse> sorry, ubuntu hardy.
[14:26] <NET||abuse> 8.04.3
[14:31] <NET||abuse> so how do i run this strace
[14:31] <NET||abuse> ?
[14:31] <NET||abuse> still sitting there for the last 4 minutes.
[14:31] <NET||abuse> ahhhhh, finished!!!!!! crap
[14:31] <NET||abuse> woah, splity
[14:35] <jam> morning all
[14:37] <vila> morning jam !
[14:37]  * vila almost miss the message in the storm....
[14:38] <vila> s/miss/missed/
[14:38] <michaelis> Hi everyone.
[14:38] <michaelis> I could use some help.
[14:40] <rubbs> what do you need michaelis
[14:41] <michaelis> If a have an old revision and update it with bzr update, then my local changes still remain intact and I have to bzr commit to update the working tree. But after running bzr update, is there a way to see what the differences are between my local tree and the tree on the server?
[14:44] <michaelis> Maybe it works as a shell command but it most certainly doesn't work in bzr-explorer.
[14:44] <rubbs> not sure if this will work but try doing "bzr diff 'Path-to-remote-branch'"
[14:44] <rubbs> oh, bzr-explorer... um. just a sec. I'll check
[14:45] <michaelis> There are possibilties to define aliases in bzr-explorer but how do I run them in the explorer?
[14:48]  * mzz wonders what RAOF is doing
[14:49] <rubbs> michaelis: I"m not sure about either of those questions :( I'm sorry. I wish igc was up.
[14:50] <rubbs> vila: do you know anything about bzr-explorer or know of anyone who does? michaelis has some advance usage questions.
[14:51] <vila> rubbs: sry, my front-end is emacs :-/
[14:52] <vila> michaelis: after an update, your working tree will be like the remote tree *plus* your local changes
[14:52] <rubbs> np... just thought I'd ask. Better to ask and be wrong rather than not ask and loose out on an opertunity for help
[14:52] <vila> michaelis: so doing 'bzr diff' will be enough
[14:52] <vila> rubbs: you're welcome, I appreciate your efforts !
[14:53] <vila> gee this IRC storm is worse every minute
[14:54] <michaelis> Wait a minute.
[14:58] <vila> ubottu: behave please, that's not how a good bot stands in a channel, your programmer will be ashamed
[14:58] <rubbs> lol
[14:59] <michaelis> But the problem is that the diff button in the explorer doesn't show the difference between two versions.
[14:59] <michaelis> But there are possibilities to define aliases. How do I run them in the explorer?
[14:59] <vila> michaelis: no idea about bzr-explorer
[15:00] <vila> michaelis: 'bzr diff' will compare your branch tip to your working tree content, there is no need to specify anything
[15:01] <vila> michaelis: just after a 'bzr update' you branch tip is the last revision commit on the remote branch, so this seems to be exactly what you want
[15:01] <vila> s/you branch/your branch/
[15:03] <michaelis> Thanks. I will try it out.
[15:12] <keithy> hi
[15:12] <keithy> sure its intendional, but its not the behaviour I need
[15:12] <keithy> maxb:
[15:18] <mzz> keithy: you may be interested in the --strict switch to commit, iirc
[15:18] <keithy> ?
[15:18] <keithy> hmm
[15:19] <keithy> I just want to tell people to do a commit
[15:19] <keithy> other tools are producing the files
[15:19] <mzz> tell them to do a commit when?
[15:19] <keithy> they work in their tools the tools product files
[15:19] <mzz> bzr isn't some background process that monitors your dir for new files
[15:19] <keithy> and at the end of the day they commit and or push
[15:20] <mzz> there are a couple of operations (like bzr st, bzr ci, etc) that look at the working tree and will notice any new files
[15:20] <keithy> well it has the notion of a directory
[15:20] <keithy> do you need to tell bzr which lines of a flie to commit?
[15:20] <keithy> bzr has directories as first class objects
[15:20] <mzz> did you actually look at the --strict switch to commit I just mentioned?
[15:20] <keithy> yes
[15:21] <mzz> ok
[15:21] <keithy> so the response form commit is to tell me to go and add files manually
[15:21] <mzz> it's probably not hard to add a commit-like command or another switch to commit that just has it add any unknown files before committing
[15:21] <mzz> would that actually do what you want?
[15:21] <keithy> I guess I want a
[15:21] <keithy> bzr add --auto blah/
[15:21] <mzz> of course simply calling "bzr add; bzr commit" where you're currently running "bzr commit" would work too, in that case.
[15:22] <mzz> adding some extra metadata to tracked directories that tells bzr they should get this automagic behavior seems like a hassle
[15:35] <michaelis> Hi again.
[15:37] <michaelis> When I select a branch in the repository I in the bottom window of the explorer that the text "no parent location selected yet" is showing. What does this mean and how do I fix it?
[15:38] <michaelis> repository I in = repository I see in
[15:43] <michaelis> I'll come back tomorrow and ask the same question. Bye.
[16:03] <NET||abuse> ok, bzr crash on trying to check out a large repo, 3.1GB, probably due to backup files being included.
[16:03] <NET||abuse> data files in forms of documents and in form of uploaded mp3'aac's and other audio files. etc
[16:04] <NET||abuse> maybe i should cut them
[16:05] <keithy> mzz: hassle? it seems obvious to me
[16:05] <keithy> its hassle not having it
[16:06] <mzz> keithy: please don't enable it for me, I'd end up accidentally checking in backup files and having to uncommit them a countless number of times
[16:07] <keithy> k
[16:07] <keithy> np I wont
[16:10] <idnar> I'm surprised there isn't a bzr commit --add or somesuch
[16:15] <quicksilver> I use bzr add `bzr unknown` quite often
[16:15] <quicksilver> and sometimes bzr add `bzr unknown | grep -v no_not_that`
[16:21] <keithy> ooo interesting
[16:23] <quicksilver> keithy: typo, by the way. the command is unknowns, with an s on the end :)
[16:35] <NET||abuse> aghghh
[16:35] <NET||abuse> getting bzr: ERROR: zlib.error: Error -3 while decompressing: incorrect data check
[17:12] <jam> vila: today is the day to cut 2.0.4 and 2.1.0rc1, do you know of anything pending that needs looking at?
[17:13] <vila> jam: plain and simple: no, I'm pretty sure we landed everything timely
[17:15] <vila> jam: if you need a nudge to land your autopack fix in rc1 I can do that for you :)
[17:15] <jam> vila: its in pqm now
[17:15] <jam> the ignore exceptions is something I'd like to land
[17:16] <vila> jam: AIUI you're waiting for some feedback on perfs
[17:16] <jam> they are correct enough for rc1, perf improvements can happen for 2.1.0 final
[17:16] <jam> as a feature change, I think 2.1 is either all-or-nothing
[17:17] <jam> Whitley didn't seem to respond to my last message, so I might pick that up myself
[17:18] <maxb> Ooi, is it likely that 2.1.0rc1 will enter ~bzr-beta-ppa? That ppa is looking a bit unmaintained at the moment
[17:25] <jam> maxb: afaik it is unmaintained
[17:25] <bialix> interesting... merging 3 times with default merge algorithm, --weave and --lca produce 9, 9, and 11 conflicts
[17:25] <jam> I certainly would like it to...
[17:25] <bialix> is it normal that --lca produce extra conflicts?
[17:26] <bialix> hi jam
[17:26] <jam> bialix: as always "it depends" but I do know of cases where --lca conflicts and --weave doesn't
[17:26] <jam> and IME it conflicts more than weave
[17:26] <bialix> rarely I saw --lca produce less conflicts than --weave
[17:26] <bialix> but very rarely
[17:26] <bialix> as you say it depends
[17:27] <bialix> but in most cases weave rules
[17:27] <bialix> but today there is no criss-cross
[17:31] <maxb> jam: Hmm.... if I was interested in helping it becoming maintained, how would I proceed?
[17:32] <jam> maxb: as in, you personally maintaining it?
[17:33] <maxb> I'm not sure I'd have the time to cover all the plugins on my own, but I'd certainly be interested in doing bzr and bzrtools
[17:35] <jam> maxb: I believe we have some documentation on how to build, etc bzr for the ppa in 'doc/developers/ppa.txt'
[17:35] <jam> with possibly some other needed info in 'releasing.txt', etc.
[17:35] <jam> IIRC, johnf (who maintains ~bzr ppa) actually uses a slightly different methodology
[17:36] <jam> but hasn't had time to update the documentation, etc.
[17:36] <maxb> Perhaps the best way would be for me to set up a personal ~maxb/bzr ppa, do some packaging, and then find someone with ~bzr-beta-ppa upload permissions to review?
[17:36] <jam> (using autoppa to handle releasing for many different platforms, etc.)
[17:36] <jam> maxb: that would work
[17:36] <jam> it would also let you experiment and get it right before we start having you send it on to others :)
[17:36] <jam> btw, I have permissions
[17:36] <jam> as do all core devs, I believe
[17:37] <NET||abuse> hmm, when you branch do you use a command like   #> bzr branch bzr+ssh://user@ipaddr/var/www/webxyz/bzrsrc ./localdir
[17:37] <NET||abuse> as i tried that and it was throwing libgz errors
[17:38] <maxb> jam: If the PPA is known currently unmaintained, it would be useful to users if you could edit its description to declare that, for now
[17:40] <jam> NET||abuse: that looks approximately correct. If you are getting libgz errors that normally indicates disk corruption
[17:42] <NET||abuse> jam, wasn't at all, if i leave out the localdir location it works fine.
[17:43] <jam> NET||abuse: that would indicate that the corruption is in "localdir"
[17:43] <NET||abuse> localdir didn't exist
[17:43] <jam> NET||abuse: if "bzr branch $SOURCE" works but "bzr branch $SOURCE ./target" doesn't, then something is pretty odd
[17:43] <NET||abuse> yup,,
[17:44] <vila> transient network error ?
[17:44] <NET||abuse> if i try ./target when the dir exists, i get the already exists error
[17:44] <NET||abuse> so i know i have to specify a non existant directory
[17:45] <NET||abuse> transient: i'm on heanet, nation education authority network, very reliable,, no way it screwed up 3 times in a row.
[17:46] <jam> NET||abuse: just as a strawman, try "bzr branch $SOURCE bzrsrc" which should be the default target
[17:46] <jam> alternatively... what does 'bzr info' in the local dir say?
[17:47] <NET||abuse> jam, well i've already downloaded it so what can i do..
[17:47] <NET||abuse> trying again
[17:49] <NET||abuse> the localdir says standalone tree( format: 2a) branch root: .   Related branches: parent branch: bzr+ssh://user@ipaddr/var/www/webxyz/bzrsrc
[17:49] <NET||abuse> and that's after trying to branch and failing.
[17:49] <jam> NET||abuse: it is possible that creating the branch succeeded but building the working tree failed
[17:50] <jam> in the localdir, you could try
[17:50] <jam> rm -rf .bzr/checkout; bzr co
[17:50] <NET||abuse> http://paste.pocoo.org/show/168068
[17:50] <NET||abuse> that's the crash log.
[17:51] <NET||abuse> jam, that sounds right.
[17:51] <NET||abuse> jam, did that, immediately again it tries to export the update and gets the error
[17:52] <jam> NET||abuse: so I don't quite understand why it would not fail if you did not supply a target
[17:52] <jam> understanding the difference may be the key
[17:52] <NET||abuse> yeh i know, i've no idea why,
[17:52] <jam> because *that* traceback clearly indicates garbage data
[17:52] <NET||abuse> but every time i specify a locadir rather than letting it default to bzrsrc?
[17:53] <jam> NET||abuse: is there a 'bzrsrc' already?
[17:53] <NET||abuse> it's really weird behaviour.
[17:53] <NET||abuse> nope
[17:53] <NET||abuse> bzrsrc is only on remote
[17:53] <jam> (note you can also always do "bzr branch ...; mv bzrsrc localdir"
[17:53] <NET||abuse> yeh, i've done that already.
[17:53] <NET||abuse> i have /home/me/development/projectxyz
[17:53] <NET||abuse> so i've about 20 projectxyz's on the go in there
[17:54] <NET||abuse> for different sites, bits of code work i do,
[17:55] <NET||abuse> and my normal method of working on a site is in the user dir for the site admin, which usually has a www or web dir adjacent, is to create bzrsrc on all hosts i work on, then i can just copy the web dir's out of bzrsrc WT on the server to live serving location.
[18:01] <gerard> anyone already wrote a testcase for bug #113809?
[18:01] <gerard> otherwise I'm going to do that now
[18:18] <jam> gerard: are you talking about the discussion from here: https://code.edge.launchpad.net/~craighewetson/bzr/update_with_local_commit/+merge/10320
[18:18] <jam> AFAIK, nobody has stepped up to complete it
[19:55] <gerard_> davidstrauss: I'm looking at bug #113809 and I've got some questions
[19:55] <gerard_> you wrote the original patch right?
[19:56] <davidstrauss> gerard_: yes
[19:57] <gerard_> I made some minor changes, and wrote a blackbox test script
[19:57] <gerard_> but I'm wondering what bzr is supposed to do for the test_smoke_update_checkout_bound_branch_local_commits test
[19:58] <gerard_> because my patched version now give the error that there are both uncommitted changes and local commits, and that seems right
[19:59] <gerard_> I'm a little confused about the situation there.... its a lightweight checkout of a branch (and a master)
[20:00] <gerard_> and it does 1 commit to the master and 1 to the branch
[20:00] <gerard_> then it makes some changes in the lightweight checkout
[20:00] <gerard_> after that, it runs bzr update
[20:02] <gerard_> I'd expect it to only get the changes from the branch
[20:03] <gerard_> but it seems the smoke test (and current implementation) also expects the commit on master to show up
[20:04] <gerard_> davidstrauss: any ideas?
[20:05] <davidstrauss> gerard_: My fix does not affect lightweight checkouts
[20:05] <davidstrauss> gerard_: Lightweight checkouts cannot handle local commits
[20:05] <davidstrauss> gerard_: Nor did I write that test :-)
[20:07] <gerard_> bzr blame to the rescue ;)
[20:07] <gerard_> vila: you there?
[20:08] <gerard_> davidstrauss: it seems my adaptation of your fix does affect lightweight checkouts :p
[20:08] <davidstrauss> gerard_: Nor should it. My fix is irrelevant to lightweight checkouts.
[20:10] <gerard_> yeah, it should be
[20:15] <NfNitLoo`> Hrmm.
[20:15] <NfNitLoo`> can I not rebase in a bound branch?
[20:16] <NfNitLoo`> bzr: ERROR: Bound branch BzrBranch7('file:///home/codyc/bzr/smartbear/wc/') is out of date with master branch BzrBranch7('file:///home/codyc/bzr/smartbear/dynreport-newcols/').
[20:16] <NfNitLoo`> I start with a clean checkout.  then try to rebase.
[20:17] <NfNitLoo`> then I get the above error and get a working-tree with an odd state.
[20:17] <NfNitLoo`> I'll try it in a standalone branch.
[20:21] <NfNitLoo`> yeah, seems to be working much better w/o the bound branch.
[20:21] <NfNitLoo`> maybe it should warn you about that?  ;)
[20:35] <gerard_> how can I check I'm in a lightweight checkout?
[20:42] <NfNitLoop> gerard_: gerard_ bzr info, I think.
[20:42]  * NfNitLoop checks.
[20:42] <NfNitLoop> yep, the Location: will say "light checkout root: <rootdir>"
[20:45] <gerard_> this looks like the check it is using: if (tree is not None and tree.bzrdir.root_transport.base != branch.bzrdir.root_transport.base)
[20:45] <gerard_> hmmm
[20:49] <gerard_> gmbl
[20:50] <gerard_> the real problem here seems to be that bzr update will happily do a string of merges, even if there are conflicts along the way
[20:50] <gerard_> so if you update, it will merge with the branch you bound to, and then with the branch that branch is bound to etc etc
[20:52] <fm_> just found an easily reproducable bug in bzr-gtk see https://bugzilla.redhat.com/show_bug.cgi?id=557573
[21:42] <gerard_> is Robert Collins around?
[21:46] <jam> gerard_his handle is lifeless
[21:46] <jam> and he pretty much always lurks :)
[21:46] <jam> I think he is at LCA this week, so I don't know if will be around to answer right away
[21:55] <gerard_> ok
[21:55] <gerard_> currently bzr update will keep on merging as long as it encounters a bound branch that is not up to date
[21:56] <gerard_> I think it should stop after one merge and notify the user
[21:57] <gerard_> because the way it currently is causes a mess with local changes and bound branches
[21:58] <gerard_> even when there are no local changes but just conflicts between commits on the chain from master to bound branch to bound branch to bound branch
[21:58] <gerard_> I found a comment in the code wondering if it is such a wise Idea to allow binding to an already bound branch
[21:59] <Glenjamin> jfroy: are you around at all? i'm having some problems getting bzr-keychain to do anything
[22:02] <NfNitLoop> gerard_: whoah, I never even thought of doing that.
[22:02] <NfNitLoop> (binding to a bound branch.)
[22:03] <Glenjamin> does that chain?
[22:03] <gerard_> I think so....
[22:04] <gerard_> but you can get conflicts in the conflicts in the conflicts currently
[22:04] <jam> Glenjamin, gerard_: no, commit will stop if it sees a bound branch of a bound branch
[22:04] <gerard_> so you can end up with a file.moved.moved etc
[22:04] <jam> gerard_: the update you are talking about is different
[22:04] <gerard_> jam: commit will, but update wont
[22:04] <jam> and has to do with local commits + local changes + remote ones
[22:05] <jam> gerard_: I'm not positive, but i'm pretty sure it only looks at 1 master
[22:05] <gerard_> jam: really?
[22:05] <gerard_> hmm
[22:05] <jam> gerard_: yep, but in a heavyweight checkout you have
[22:05] <jam> 1) the current revision of the working tree
[22:05] <jam> 2) local modifications to the working tree
[22:05] <jam> 3) the current revision of the local branch
[22:05] <jam> 4) the current revision of the master branh
[22:05] <jam> branch
[22:06] <jam> and 'update' is currently designed to "smush" that so that
[22:06] <jam> 1 == 3 == 4
[22:06] <gerard_> and we can only do a 3 way merge
[22:06] <gerard_> forcing people to do a local commit first isn't going to work
[22:06] <kbrown> hi, I'm in the process of installing the latest Bazaar on OS X 10.6.2, found I had a previous v 1.3 installed apparently. Is there an uninstaller for 1.3 somewhere? Or what do I need to do to get rid of it?
[22:07] <gerard_> because there are lightweight commits
[22:09] <gerard_> so we should just do one of the merges (3,1,2)
[22:09] <gerard_> and then push
[22:09] <zsquareplusc> hmm, the fist time a package fails to install... and it's the bzr upgrade in karmic..
[22:10] <gerard_> hmmm
[22:10] <gerard_> this is hard
[22:10] <gerard_> for a lightweight 1 == 3 right?
[22:11] <gerard_> ah, it doesn't have to
[22:18] <NfNitLoop> kbrown: I generally just run the installer and it will overwrite the old version.
[22:19] <NfNitLoop> kbrown: if you want to be paranoid, you could find the bzrlib directory in your python libraries and delete it.
[22:20] <kbrown> the one issue I discovered was bzr was in /usr/bin before and now is in /usr/local/bin, when I did bzr from Terminal it does not pick up the correct one it seems
[22:20] <NfNitLoop> kbrown: aah, yep.  Delete the old one.
[22:20] <NfNitLoop> kbrown: I have also wished for an uninstaller, but I don't think there is on. :/
[22:20] <NfNitLoop> one*
[22:21] <kbrown> did that, I suppose the bzrlib is ok then after the new install?
[22:23] <NfNitLoop> kbrown: Yep.  the bzr executable will complain otherwise.
[22:23] <NfNitLoop> (It'll tell you that the exe and library versions differ.)
[22:24] <gerard_> bzr log doesn't show revision 0?
[22:25] <fullermd> No, rev0 doesn't exactly exist.
[22:25] <gerard_> aww
[22:25] <gerard_> that's the classic vcs problem
[22:25] <lifeless> revision 0 is a theoetical thing
[22:25] <fullermd> It got caught in flagrante delicto with rev -1, so we banned it for life.
[22:25] <gerard_> so I can have a theoretical thing with a date and a commit message?
[22:25] <gerard_> doesn't sound too theoretical to me
[22:26] <kbrown> NfNitLoop: thx
[22:26] <gerard_> lifeless: anyway, I wanted to ask you something
[22:26] <gerard_> about the double merge that bzr update sometimes does
[22:27] <gerard_> if the first step has a conflict things get seriously messed up
[22:28] <gerard_> I did quite some bzr annotate and it seems you were the one to add that second merge
[22:28] <lifeless> yes
[22:28] <lifeless> so bzr should just stop there
[22:29] <gerard_> that's my current assumption
[22:29] <gerard_> but I'm not too sure
[22:31] <lifeless> I've checked with abentley who wrote the main merge code and he still thinks stopping there would be good
[22:32] <gerard_> does the rest of the code allow a commit after the merge stops at that point?
[22:33] <gerard_> something in the situation has to change, otherwise rerunning merge will not have any effect
[22:33] <gerard_> ehm, rerunning update*
[22:36] <lifeless> fix the conflict, run update again.
[22:36] <lifeless> should work f ine in the postulated situation.
[22:36] <lifeless> bbiab, fooding
[22:36] <gerard_> so only stop when there is a conflict?
[22:36] <gerard_> because it seems the policy of bzr to always explicitly commit after a merge
[22:41] <lifeless> yes, that should be fine here.
[22:41] <lifeless> you won't need to commit after the first merge in this situation.
[22:42] <lifeless> because its an update.
[22:42] <Kilroo> I keep feeling like I've almost found the silver bullet, and then realizing I skipped a step.
[22:43] <Kilroo> A lot of the stuff I deal with at work is still on raw FTP with no source control, despite a very slow process that has been under way for several months now to try to move everything to svn (and the stuff that is on svn so far is doing it wrong).
[22:45] <Kilroo> I was trying to figure out a way that I could still use bzr to make my own life easier, but I keep running up against the fact that in order for it to work, either everyone else would have to stop doing direct ftp, or I'd have to be able to install bzr on the server.
[22:45] <Kilroo> Oh well.
[22:47] <NfNitLoop> Kilroo: sounds like a good time to look for a new job? :p
[22:47] <fullermd> I was thinking that a silver (or other metal) bullet would be a useful tool to stop the direct FTP   8-}
[22:47] <NfNitLoop> Seriously.  If you're at a company that's seriously doing development via ftp in 2010... run.
[22:48] <Kilroo> Yeah, well, if I can get them to stop dumping major database projects on me for a little while, I'm going to try to do something to change that.
[22:52] <Ddorda> can anyone help me? bzr doesn't want to upload my new branch. Ive done init and add, but it says I don't have permissions when it gets to push...
[22:52] <Kilroo> Unfortunately my campaign is going to involve going up against a systems administrator who is leery of DVCS (and I think might actually like cvs better than svn) and thinks fusionforge is good stuff, and two levels of supervisors who are going to be very hard to sell on using something like Redmine instead of the VIP Task Manager program we're using now...
[23:07] <Kilroo> I've been reading through some stuff about the differences between git and bzr lately. It can get pretty interesting.
[23:07] <gerard_> lifeless: not performing the second merge loses your uncommitted changes
[23:08] <gerard_> it's the first that needs skipping
[23:08] <Kilroo> One sentence I thought was pretty apt in a lot of ways was something along the lines of how git focuses more on the code and bzr focuses more on the developer.
[23:09] <gerard_> Kilroo: I like the power of git, but I'm pleasantly surprised by the versatility and code quality of bzr
[23:10] <gerard_> M1->M2  M1->B2 M1->(uncommitted changes)
[23:10] <NfNitLoop> Ddorda: Did you forget a 'bzr commit' step?   also, bzr push *will* fail if you don't have write permission.  What type of location are you pushing to?
[23:11] <gerard_> first step: M1->M2 M1->B2->(uncommitted changes) M1->B2->(uncommitted changes)
[23:11] <gerard_> second step: M1->B2->M2->(uncommitted changes) ... ...
[23:11] <gerard_> seems the most logical to me
[23:16] <Kilroo> In some ways it seems to me that the way git evolved is (very) roughly analogous to coming up with the 2a format and then building bzr to interact with it
[23:17] <gerard_> yeah
[23:17] <gerard_> and building it using mostly shell scripts
[23:18] <gerard_> but still, it works quite well for such a big hack
[23:19] <Kilroo> One of the assertions made a few years ago by a git advocate regarding whether bzr is truly distributed also led me to thinking that one of the key differences in philosophy between the two is that git is sort of distributed from the ground up, whereas bzr is distributed more as the logical extremity of starting from the centralized mindset and decentralizing it.
[23:19] <lifeless> gerard_: uh
[23:19] <gerard_> hehe
[23:19] <lifeless> gerard_: I don't quite follow, but I'm tired after a week of conference
[23:19] <lifeless> put it in the bug please, so I can mull on it. Note that *both merges are needed*. But we can choose to do one later.
[23:19] <gerard_> what I mean if that a checkout has local changes, those need to go to the bound branch first, and only with the second update + commit they go to the master
[23:20] <gerard_> I'm tired too, it's getting late
[23:20] <gerard_> I'll attach what I have now to the bug
[23:21] <Kilroo> Or to put it another way, git is (to put it in git terms) a content-addressable file system with version control built on top of it and collaboration built on top of that, whereas bzr is a version control system that is largely designed for collaboration but works quite well for solo work anyhow.
[23:23] <Kilroo> I think I'll stop making vague comments about stuff I halfway understand now. At least for a little while.
[23:24] <Kilroo> I still think it's funny that bzr can do a better (or at least easier) job of fixing the wrong way we're using subversion than subversion can though. Even without switching to bzr.
[23:26] <Kilroo> ...in case you're curious...for some strange reason, the projects that have already been moved to subversion have a production repository and a development repository, instead of branches. It's basically like having plain ftp with a production server and a dev server, except with history and accountability.
[23:27] <Kilroo> But it does still beat having ONE server with a lot of files named things like index_v2_test4.php
[23:27] <igc> morning
[23:28] <Kilroo> maurng.
[23:34] <gerard_> Kilroo: some people clearly don't understand the idea of version control
[23:35] <gerard_> but well, sometimes I don't either
[23:35] <gerard_> confusing stuff
[23:37] <Kilroo> gerard_: I think part of the issue is that for a while the development team was either small enough or having enough turnover that nobody even thought about how good an idea version control would be long enough to do anything about it
[23:37] <gerard_> when I started at my job a few months ago they weren't using any vcs ;)
[23:38] <gerard_> I am the 4 developer so it isn't that big of a team
[23:38] <Kilroo> To be honest, at first I wouldn't even have understood the problem with the way we're using svn.
[23:39] <Kilroo> The only source control I'd used before was VSS with a max of four developers (two most of the time I was there).
[23:39] <Kilroo> I actually came across bzr specifically because of its ability to use an ftp dumb server, and branched out to learn about git and hg and darcs and so forth from there.
[23:40] <Kilroo> I keep meaning to sit down and write out a thorough explanation of how awesome a DVCS would be and how svn would be inferior and try to push for adoption.
[23:42] <Kilroo> I have to admit, though, that despite how much I like bzr, I'm tempted to try out the other alternatives and make my final recommendation based primarily on which one has the best eclipse plugin. Which I suspect at the moment might be Mercurial.
[23:48] <mzz> Kilroo: I'm not a heavy svn user, but afaik the idea is for bzr to be a *superset* of svn, not just an alternative. So other than various kinds of inertia (learning slightly different tools, converting repos, etc) bzr is imho a better choice than svn
[23:50] <Kilroo> mzz: I agree. Matter of fact, now that the latest beta of bzr seems not to choke on our svn repositories, I am hoping to find time to set up so that I am at least using bzr as an svn superclient and for local branching, even if I can't sway the powers that be on the main choice.
[23:51] <mlh> svn is a worse choice than bzr,git,hg in every aspect except unfortunately where it matters: mind share and tool/system/ide integration
[23:52] <Kilroo> From what I've gathered, while some things I've read seem to imply that git-svn has had the shortest cumulative duration of not working due to new releases of one side of it or the other, bzr works more seamlessly with svn than any of the other DVCS bridges.
[23:52] <ronny> mlh: well, my ide has better hg/git/bzr inregration than svn integration :P
[23:53] <mlh> er, change 'matters' for 'sometimes matters for organisations in a corporationy way'
[23:53] <mlh> ronny: NICE!
[23:53] <gerard_> lifeless: attached a patch to prevent update when there are local changes + local commits
[23:53] <mlh> what ide .. emacs?
[23:53] <ronny> mlh: pida
[23:53] <gerard_> might have some time to look at stopping after the first merge this weekend
[23:53] <ronny> mlh: well,, partial reason is - i coded the current vcs integration, and svn just sucked
[23:53] <ronny> even worse than git
[23:55] <Kilroo> I also haven't really gotten the impression that any of the other DVCSes besides bzr are particularly interested in working on two-way integration with the other tools. Imports, yes. Exports, maybe. Use X to work directly with repositories of Y...bzr seems to be the only one pushing for it much.
[23:55] <ronny> bzr/hg works best, but i strongly prefer hg cause its api works like my mind ticks
[23:55] <ronny> Kilroo: there is hg-git, hg-svn, and jelmer pushes for a hg-bzr based on bzr-hg
[23:56] <ronny> and git is kind of lost, cause it lacks custom metadata
[23:57] <Kilroo> ronny: I think I'd noticed hg-bzr but hadn't come across hg-git. And I'd almost be inclined to consider that to be bzr pushing for hg-bzr more than hg pushing for it, 'coz I mostly know of jelmer for his bzr work.
[23:57] <ronny> Kilroo: jelmer is a bzr core dev
[23:58] <ronny> well, and it is based on bzr-hg
[23:58] <ronny> there is a certain metadata gap, cause hg handles file-histories different than bzr
[23:58] <Kilroo> He could have just been a casual contributor and that would still be what I knew him for. The only dev whose name I've really latched onto for any of the others is, uh, Torvalds.
[23:59] <ronny> yes, that borderline nut with too much media pressence :P