[01:01] <davidstrauss> lifeless: Is there a way to manually manipulate merge data?
[01:01] <davidstrauss> lifeless: Like, let's say you commit a merge to a public branch. You can't uncommit, but you want to revert the merge *and* have the merge tracking data reflect that.
[01:04] <fullermd> No, because there isn't "merge tracking data", there's only ancestry.
[01:08] <davidstrauss> fullermd: Is it possible to "unzip" part of the ancestry?
[01:11] <fullermd> Yeah, with uncommit   8-}
[01:15] <davidstrauss> fullermd: but that works poorly for public branches
[01:16] <davidstrauss> fullermd: other people's checkouts show the removed commits as "local commits"
[01:21] <fullermd> Well, that's the fallout.  You can't have something in your ancestry and not in your ancestry at the same time.
[01:21] <fullermd> And making ancestry somehow nontransitive would just be unutterably evil.
[01:25] <davidstrauss> fullermd: ideally, we'd have a way to record the reversal
[01:31] <fullermd> Well, ideally a lot of things.  But that would be a very fundamental change.
[03:52] <taxilian> anyone here used the webdav plugin for bzr that might be able to help me figure out why I can't push or commit over webdav?  it keeps telling me that it can't obtain the lock
[03:53] <taxilian> and then sits there forever and dies
[04:58] <lifeless> 4/quit
[10:16] <jelmer> taxilian: vila is the best person to talk to about the webdav plugin
[15:37] <jjann> Hi. I have some checkouts of bzr and svn repositories in one of my repositories. I don't want to treat them special (ie use some externals mechanism or something), just add them with their repository meta-data, how can I do this?
[15:38] <jjann> right now, bzr status shows me the contained repos' top level directories as unknown but bzr add doesn't add them
[15:39] <jjann> (even a 'bzr add -v some_contained_repos_toplevel' just prints out nothing and some_contained_repos_toplevel/ just keeps showing up as unknown in bzr status)
[15:39] <jjann> (I'm using bzr 2.1.1 on lucid)
[15:42] <jelmer> jjann: hi
[15:42] <jelmer> jjann: if you want bzr to just treat the .svn directories as data, uninstall bzr-svn
[15:43] <jjann> jelmer: hm, I use bzr-svn on other repositories though. and what about the .bzr directories?
[15:44] <jjann> essentially you're saying I really should be using externals?
[15:44] <jelmer> jjann: I don't think there is any way to treat .bzr directories as plain data
[15:45] <jjann> ok, bzr-eternals it is then, thanks
[15:46] <jjann> let's hope I'll get by with this better than I did with mercurial subrepos :)
[15:54] <jjann> I'm confused. I installed bzr-externals, I deleted one of the bzr subrepos, I did 'bzr eadd lp:foo the_dir; bzr ci -m "add lp:foo"'
[15:54] <jjann> and after that, the_dir/ still shows up as 'unknown' in bzr status
[15:55] <jjann> ok, seems to be some broken old state from previous attempt, doesn't happen in a fresh clone. sigh. :-)
[15:56] <jelmer> jjann: I'm not entirely sure if bzr-externals will do what you want
[15:56] <jelmer> it won't allow you to use 'bzr add' as far as I know
[15:56] <jelmer> it will will in a way similar to svn:externals
[16:04] <jjann> yeah, it uses 'eadd', which I did
[16:04] <jjann> I was just surprised that the newly added external shows up as 'unknown' in the status output
[16:06] <jjann> but it seems similarly underused and underdocumented as hg subrepos. I keep wondering how most users seem to get by without such a feature. git really is the only one of the 'modern' DVCSes that takes this seriously :(
[16:07] <jjann> (but git was rejected quite early in our evaluations to find a replacement for svn for various other reasons)
[16:08] <jelmer> jjann: bzr-externals are a hack for the fact that nested trees aren't supported in bzr yet
[16:09] <jelmer> jjann: we've been planning that feature for ages but it keeps stalling because we haven't managed to design something that works well in all cases, scales and doesn't require a lot of special casing
[16:09] <jjann> initially I was hoping to get by with adding the .svn and .bzr directories as plain data since bzr has the nice advantage of tracking directories as well as files (the lack of that feature is the reason that treating svn checkouts as normal data doesn't work in hg for example)
[16:09] <jelmer> jjann: alternatively  you can use the --no-plugins argument when adding .svn directories
[16:10] <jjann> that still would only solve half my problem. I'm currently considering hacking my own super low-tech variant, just renaming .bzr and .svn repos pre and post update
[16:10] <jjann> s/repos/directories/
[16:11] <jelmer> jjann: is there any reason for wanting to keep the other repositories' control directories around, rather than merging them in?
[16:12] <jjann> jelmer: they are repositories that don't belong to me and that I want to be able to update easily during project lifetime (ie they are external library dependencies and somesuch)
[16:12] <jelmer> jjann: you would simply be able to merge in newer versions still
[16:13] <jelmer> jjann: as bzr remembers the common history with those projects
[16:13] <jjann> by keeping their meta-data around, I can browse their changelog, I always know what revision of them I have
[16:13] <jjann> hm
[16:13] <jjann> can I merge a repo inside a sub-directory of my repo?
[16:13] <jjann> ie bzr merge lp:foo libs/foo?
[16:13] <jelmer> jjann: yes, although it works a bit different from that
[16:13] <jelmer> jjann: you'd want to use "bzr join" to combine the two repositories originally
[16:14] <jelmer> after that you can use "bzr merge"
[16:14] <jjann> oh, never even read about join, thanks!
[16:18] <jjann> I must admit I don't get how exactly join works (or what exactly it does) from its help output. the naive variant of 'bzr join lp:foo' doesn't work at least and I'm not even sure that's what I want
[16:18] <jelmer> jjann: if you want to have lp:foo live at lib/foo you would run something like:
[16:18] <jelmer> bzr branch lp:foo lib/foo; bzr join lib/foo
[16:19] <jelmer> bzr commit -m "Merge in lp:foo"
[16:19] <jelmer> After that "bzr merge lp:foo" will do the right thing and update just lib/foo
[16:19] <jjann> brilliant, thanks
[16:23] <jjann> and it works perfectly with svn repos as well, nice
[16:24] <jjann> also, I love the "revision folding" bzr does, with the nice folder-like feeling in qlog, fits perfectly here
[16:25] <jjann> I really must say, when I started evaluating bzr, hg and git, bzr was the one I had heard the most bad things about and still it keeps comming out on top now that I'm actually testing it myself
[16:25] <jjann> so there really needs to be some publicity work done I think ;)
[16:29] <jelmer> jjann: Great to hear, thanks :-)
[16:29] <jelmer> jjann: Our initial performance issues have caused a lot of harm I think.
[16:30] <jjann> right "it's too slow!" was one of the things I heard most. also "it changes it's repository format like every release, it can't be stable/good"
[17:13] <abostrom> hum
[17:14] <abostrom> help needed: i have committed three patches to my branch. if i do "bzr bundle", i get a single patch.
[17:15] <abostrom> do o need to send three bundles upstream if i want to preserve history? or are the patches hidden somewhere in the blob at the end?
[17:15] <jelmer> abostrom: they're in the blob at the end
[17:18] <abostrom> ok, but if i make a fresh branch and merge my bundle, i get only a single commit
[17:18] <abostrom> trying merge -r gives "bzr: ERROR: Cannot use -r with merge directives or bundles"
[17:20] <abostrom> aaah
[17:20] <abostrom> bzr log --include-merges
[17:20] <abostrom> i see
[17:21] <abostrom> thanks :)
[17:23] <jelmer> np :-)
[18:28] <assad> while doing a bzr diff between two branches: bzr diff --old ARG it says branch ARG , so how do i access the branch name? is it some relative addressing ?
[18:28] <assad> what is ARG equal to in that command
[23:00] <wamills> Hi,  I'm new to bzr, but know git.  I am trying to create a branch from a lp tag.  Which of these commands does that?
[23:04] <lifeless> what do you mean by 'lp tag'
[23:09] <jelmer> 'morning lifeless
[23:09] <lifeless> hi jelmer
[23:09] <lifeless> wamills: what do you mean by 'lp tag'
[23:11] <wamills> OK I made a branch of gnome-terminal but it is the latest development.  I want to create a branch based on 2.29.6 tag. Like is used in the current Lucid package
[23:12] <wamills> git checkout -b my-fix 2.29.6
[23:14] <lifeless> tags in bzr are a property of a branch
[23:14] <lifeless> so you need to know what branch the tag is in
[23:15] <lifeless> if you want a branch of the lucid package for gnome-terminal, you can do 'bzr branch lp:ubuntu/lucid/gnome-terminal
[23:16] <lifeless> and you can query the tags with 'bzr tags -d lp:ubuntu/lucid/gnome-terminal'
[23:17] <wamills> OK, my first error was starting with the wrong base.  I guess lp:gnome-terminal is just tracking upstream yes?
[23:18] <lifeless> yes
[23:18] <wamills> OK let me get to the right project.
[23:24] <wamills> OK so 2.29.6-0ubuntu5 is the latest tag so I could make changes. commit & push to personal branch right?
[23:24] <lifeless> yes
[23:24] <lifeless> if you're making a patch for ubuntu you don't need to worry about tags at all though
[23:24] <lifeless> just
[23:25] <lifeless> bzr branch lp:ubuntu/lucid/gnome-terminal (for making a patch for lucid)
[23:25] <lifeless> hack hack hack
[23:25] <lifeless> bzr commit
[23:25] <lifeless> bzr push lp:~USERNAME/ubuntu/lucid/gnome-terminal/BRANCHNAME
[23:27] <wamills> cool.  Thats good enough for what I am doing today.  I'll RTF(abulos)M for more.
[23:27] <lifeless> please feel free to hop back in and asj
[23:27] <lifeless> its the weekend
[23:27] <lifeless> so a bit quieter than normal :)
[23:27] <lifeless> also #launchpad for launchpad questions is pretty good
[23:28] <lifeless> and #ubuntu-motu or #ubuntu-packaging for packaging related things (like how to change a package version number etc)
[23:28] <wamills> Thanks!  Good suggestions.