glyph | is there a way to customize the font used by qbzr? (in particular, on the mac) | 01:00 |
---|---|---|
methods | when i port an svn repo to bzr can i make it continue from the same revision number ? | 02:25 |
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:43 |
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 ? | 02:49 |
jelmer_ | methods: if you have only one branch, yes | 03:13 |
methods | what about svn banches... they are just copies with remembered history ... how is that transition to bzr ? | 03:15 |
jelmer_ | methods: if the branches were created by e.g. copying from trunk that relationship is preserved | 03:21 |
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:23 |
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:48 |
methods | no i never did | 03:49 |
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 | 03:50 |
methods | can I tell bzr to treate the whole svn repo as a single branch ? | 16:15 |
jelmer | methods: bzr branch <location> <new-path> | 16:19 |
methods | well I'm going to convert svn to bzr | 16:19 |
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:27 |
jelmer | methods: Yes, that's what this will do. | 16:28 |
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:03 |
jelmer | henke: I don't think I've seen it before. Have you checked the bugtracker? | 18:16 |
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:17 |
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:18 |
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:19 |
jelmer | henke: no, a/b/foo.h is being renamed to a/c | 18:21 |
jelmer | henke: assuming this is output from "bzr log -v" | 18:22 |
henke | jelmer, I used bzr diff -c <rev>, bzr log -v -r <rev> gives: | 18:24 |
henke | moment, checking something | 18:25 |
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 | 18:36 |
henke | I wonder if there's any way to reconstruct the repo so that it makes sense at that point | 19:02 |
jelmer | henke: I doubt that would be related, this more looks like a bug in bzr-fastexport. | 19:12 |
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:16 |
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:41 |
jelmer | henke: right, that's a valid operation in bzr (albeit a bit strange) and I suspect bzr-fastexport doesn't expect that | 19:42 |
henke | it seems very strange to rename a file into a directory | 19:43 |
henke | jelmer, thanks for the help, it seems like I managed to make a temporary fix that works | 20:10 |
=== frakturfreak_ is now known as frakturfreak |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!