[01:00] <glyph> is there a way to customize the font used by qbzr?  (in particular, on the mac)
[02:25] <methods> when i port an svn repo to bzr can i make it continue from the same revision number ?
[02:43] <jelmer_> methods: Hi
[02:43] <jelmer_> methods: Depending on how you do the conversion it should still show the old revision numbers in "bzr log"
[02:43] <jelmer_> methods: We can't really keep using the same revision numbers - you'd get gaps as bzr's revision numbers are per-branch whereas they are per-repository in svn.
[02:49] <methods> yea but if the initial import of the svn history is in the main branch then the main branch should be boot strapped to the last svn number + 1 or somthing right ?
[03:13] <jelmer_> methods: if you have only one branch, yes
[03:15] <methods> what about svn banches... they are just copies with remembered history ...  how is that transition to bzr ?
[03:21] <jelmer_> methods: if the branches were created by e.g. copying from trunk that relationship is preserved
[03:23] <methods> yea i heard that you could have issues if you didn't use a proper naming convention for folders ?
[03:23] <methods> i mean my branches were not names like branches/<name>/trunk
[03:48] <jelmer_> methods: yeah, there might be issues if you have branches in usual locations, they might not be imported as branches
[03:48] <jelmer_> methods: Since there's no real way of knowing what a branch is in svn
[03:48] <jelmer_> methods: if you use /trunk and /branches/<name> as branch names you should be fine
[03:49] <methods> no i never did
[03:50] <methods> tell you truth i don't really care it would be nice to have a way to just tell bzr to convert the whole thing as a single branch and not attempt to branchify it... you said history is remembered so that's all tha tmatters
[16:15] <methods> can I tell bzr to treate the whole svn repo as a single branch ?
[16:19] <jelmer> methods: bzr branch <location> <new-path>
[16:19] <methods> well I'm going to convert svn to bzr
[16:27] <jelmer> methods: Yes, location can be a SVN repository
[16:27] <methods> what i mean is i want bzr to not attempt to figure out branches in the svn history
[16:28] <jelmer> methods: Yes, that's what this will do.
[18:03] <henke> I am having problems using bzr fast-export on a repository of mine. I get an AttributeError that a directory doesn't have a children attribute. However, it seems to mistake a file for being a folder, related to a rename that is listed as.. 'a/b/foo.h' => 'a/c', where 'a/c' is a folder, while other renames are of the form 'a/b/bar.h' => 'a/c/bar.h'. Has anybody run into this problem?
[18:16] <jelmer> henke: I don't think I've seen it before. Have you checked the bugtracker?
[18:17] <henke> jelmer, I have been searching a bit but haven't found anything directly applicable.
[18:17] <jelmer> henke: do you have a way to reproduce it on a public repository?
[18:17] <henke> jelmer, it seems to think it is a directory rename instead of a file rename into the folder
[18:18] <henke> jelmer, unfortunately I don't. I can try to make a new repo to trigger it
[18:18] <jelmer> henke: it could be a kind change (directory being turned into a file)
[18:18] <henke> jelmer, it's a file being moved to a directory
[18:19] <jelmer> henke: the change is 'a/b/foo.h' => 'a/c' ?
[18:19] <jelmer> so "a/c" is a file?
[18:19] <henke> jelmer, yes
[18:19] <henke> jelmer, a/c is a directory
[18:19] <henke> jelmer, the file is then at a/c/foo.h
[18:21] <jelmer> henke: no, a/b/foo.h is being renamed to a/c
[18:22] <jelmer> henke: assuming this is output from "bzr log -v"
[18:24] <henke> jelmer, I used bzr diff -c <rev>, bzr log -v -r <rev> gives:
[18:25] <henke> moment, checking something
[18:36] <henke> strangely enough, it says, disregarding other files: added include/shaders/basicshader.h, renamed: include/engine/basicshader.h/ => include/shaders/, modified: include/shaders/, in the revision after the change, the file basicshader.h is located in include/shaders/
[18:36] <henke> jelmer, I think the incongruence could be due to the repo being old and having been upgraded a few times, something going awry along the way with regards to the renames
[19:02] <henke> I wonder if there's any way to reconstruct the repo so that it makes sense at that point
[19:12] <jelmer> henke: I doubt that would be related, this more looks like a bug in bzr-fastexport.
[19:16] <henke> jelmer, well, the revision that makes it crash is initially from GNU Arch, and the rename looks wonky. It's computed by the Tree.changes_from() which is not part of fast-export
[19:41] <henke> jelmer, it does seem like the file is renamed into a directory (kind-change?), and then a new file with the same contents is added to that directory
[19:42] <jelmer> henke: right, that's a valid operation in bzr (albeit a bit strange) and I suspect bzr-fastexport doesn't expect that
[19:43] <henke> it seems very strange to rename a file into a directory
[20:10] <henke> jelmer, thanks for the help, it seems like I managed to make a temporary fix that works
=== frakturfreak_ is now known as frakturfreak