[09:18] <alexlist> Hi... I am re-familiarizing myself with packaging and could need some advice ... is anyone using the (experimental) 3.0 (bzr) source format here?
[09:19] <mgz> I don't think so
[16:50] <Wiz_KeeD> hey guys
[16:50] <Wiz_KeeD> How can i set a bzr repo on a server from which i can push locally via ssh to make changes?
[16:51] <mgz> just create a branch on a server you have ssh access to
[17:05] <Wiz_KeeD> with bzr-init repo
[17:05] <Wiz_KeeD> and the bzr init
[17:05] <Wiz_KeeD> ?
[17:06] <mgz> or any other means of getting a branch on there, scp from local, for instance
[18:06] <achiang> 'allo, someone checked large binary files into our tree; i am bzr rm'ing them now, but is there a way to wipe them from history too, so that pulling the branch doesn't take forever?
[18:07] <spiv> achiang: not easily
[18:07] <achiang> bleah
[18:08] <spiv> achiang: probably the easiest path is to make a new repository from just before the point the large files were added, then rebase the later history on top.
[18:08] <achiang> spiv: ok, that seems doable
[18:08] <achiang> spiv: thanks
[18:08] <spiv> Yeah, it's doable.  Just not what I'd call easy :)
[20:44] <achiang> "The downside to cherrypicking is that Bazaar does not track cherrypicked revisions, although this feature is firmly on the wish list."
[20:44] <achiang> does this mean when i cherry pick revisions, i don't get changelogs and individual commits?
[20:44] <achiang> (because that is what i experimentally observe)
[20:46] <jelmer> achiang: basically
[20:47] <achiang> jelmer: thanks
[20:47] <jelmer> achiang: it sounds like what you want isn't actually cherrypicking tracking though - since you don't care about the relation to the old history
[20:47] <jelmer> you want to have a look at "bzr replay" from the bzr-rewrite plugin
[20:49] <achiang> jelmer: looking
[20:54] <achiang> jelmer: thanks, replay does what i want, except did i find a bug in how it handles revspecs?
[20:55] <achiang> jelmer: i did: bzr replay -r4..9 ../otherbranch
[20:55] <achiang> jelmer: and i would have expected it to commit r5, r6, r7, r8, and r9 into 'currentbranch'
[20:55] <jelmer> achiang: it's experimental, and has some known issues
[20:55] <achiang> jelmer: instead, it committed r4, r5, r6, r7, and r8
[20:57] <achiang> jelmer: fair enough, just giving a heads up that i think the behavior is different from what standard 'bzr merge' does...
[20:57] <achiang> from the bzr merge man page:
[20:57] <achiang> If you specify two values, "--revision BASE..OTHER", only revisions BASE
[20:57] <achiang>   through OTHER, excluding BASE but including OTHER, will be merged.
[20:57] <achiang> so it's like (a, b]
[20:57] <achiang> but what i got from replay was [a, b)
[20:58] <achiang> or rather, how replay handled the -r arg was [a, b)
[22:19] <rozzin> Who should I be bothering about a Windows build of Bazaar 2.6.0?
[22:22] <mgrandi> Hello, i'm curious about how bazaar 'handles' renaming of directories
[22:23] <mgrandi> Renaming a directory
[22:23] <mgrandi>     does not count as renaming all its contents.
[22:23] <mgrandi> sorry, that is a comment in delta.py, and sure enough if i get the delta of a revision that renamed a directory, the stuff inside the directory is not in any of the DeltaTree lists
[22:24] <mgrandi> err TreeDelta*
[22:24] <mgrandi> so basically i have a post commit hook that is interfacing with another version control system, and when i rename a directory i dont see that any of the stuff inside gets renamed so...im confused on how bazaar handles this
[22:25] <lifeless> the directory is a first class object itself
[22:25] <lifeless> objects in a directory tree are (parent, name, kind, mode, content) tuples, basically.
[22:26] <lifeless> a rename occurs when either parent or name change.
[22:26] <lifeless> For instance bzr mv foo bar
[22:26] <lifeless> changes the name
[22:26] <mgrandi> yeah
[22:26] <lifeless> and bzr mv foo/file bar/file
[22:26] <lifeless> changes the parent
[22:26] <lifeless> when you rename a directory: bzr mv dir1 dir2
[22:26] <mgrandi> so, how do i detect or figure out when a directory has changed for instance? like in a post_commit hook
[22:26] <mgrandi> or is there no nice way to do that
[22:26] <lifeless> the children of dir1 keep the same parent, and the same name.
[22:27] <lifeless> look at the kind
[22:27] <mgrandi> hmm.
[22:27] <mgrandi> So im guessing there is no nice way to do that
[22:27] <mgrandi> and i just have to see if its a directory
[22:27] <mgrandi> and then figure out all the 'children' of that directory then rename them in the hook? (for the other vcs)
[22:27] <lifeless> Your question has it's own answer: to see when a directory has changed, see if the thing that has changed is a directory.
[22:27] <mgrandi> yeah.
[22:28] <mgrandi> I just have to figure out whats in that directory and rename those as well
[22:28] <mgrandi> I'm using bazaar to interface with "team foundation server'
[22:28] <lifeless> yes; you'll want to exclude from that any things that have been moved outside of the directory as part of the same commit
[22:28] <lifeless> mgrandi: someone wrote a tfs plugin
[22:28] <lifeless> mgrandi: you could just use that :)
[22:28] <mgrandi> haha that would be great
[22:28] <lifeless> I *think* they released it, not sure.
[22:28] <mgrandi> mine is just a simple post commit hook that just runs add/edit/remove/rename on the tree delta stuff
[22:29] <mgrandi> but then silly things like...tfs doesn't rename stuff inside directories like bazaar does
[22:29] <mgrandi> if you could find that, that would be great.
[22:30] <mgrandi> is it this? https://launchpad.net/bzr-tfs
[22:32] <lifeless> sounds like it :)
[22:53] <mgrandi> seems like it doesn't work on 2.6, maybe have to edit it a little bit..
[22:58] <mgrandi> its trying to register a custom transport, but the method it wants isn't there anymore
[22:58] <mgrandi> BzrDirFormat.register_control_server_format(TfsControlFormat)
[22:58] <mgrandi> any idea where that got moved to?