[00:08] hi. i heard that you bazaar guys fixed some issues in python-subversion. what do such issues look like? [00:09] there are some more waiting to be fixed [00:13] bzr-svn eventually gave up on python-subversion. [00:14] what did it switch to? [00:15] maelcum: jelmer wrote something new, https://launchpad.net/subvertpy [00:17] i've had a look at python-subversion and it's a huge amount of ugly code (which might be par for the course for bindings). [00:17] i wonder how such things are created, and how to mess them up because it's supposed to be pretty much automatic. [00:18] Isn't python-subversion generated by SWIG or something? [00:19] yes. somebody still has to write the swig definitions, and there are also comments in the C sourcecode. [00:19] * Peng_ doesn't know how SWIG works. [00:19] i kinda categorized it as broken mess from hell [00:19] Ah. [00:19] yeah, that is what the code looks like anyway [00:20] svn and its libs [00:20] the parameter count of some svn methods cannot be counted on the fingers of one hand as i noticed in the bindings code, which qualifies as "bad". [00:21] s/one hand/two hands/ [00:21] this one is also made of lose: [00:21] #define SWIG_fail goto fail [00:21] oh, at least it cant kill kittens [00:22] it trips over its own fail, then a lolcat makes a phun [00:22] goto for error-out is kinda useful but hiding it is **really** stupid [00:22] its swig, it cant do any good [00:23] at least the macro name is well-chosen [00:23] nah, it clearly lacks a "is_" in the middle [00:24] hmm, is subvertpy usable? [00:25] ronny: Define "usable". bzr-svn uses it.. [00:26] stable api, works for getting workdir status indformation+ stuff like commit [00:27] (in pida we use subprocess for calling to svn, but im not happy about that) [00:27] ronny: I dunno. You should talk to jelmer about it. [00:28] I'm still having issues getting TortoiseBzr to work on my computer, and I think its because I'm running Windows Vista 64 [00:29] any possible workarounds [00:29] ronny: At this point, it probably just does whatever bzr-svn needs, and bzr-svn can do "status" and "commit" on svn checkouts. [00:30] hmk [00:31] * Peng_ doesn't atually know anything. [00:31] actually* [00:31] i'll bookmark it and figure stuff out when i work on anyvc again [01:12] subvertpy ? [01:13] oh I see [01:13] pulled out to a new package [01:56] Is there any way to get TortoiseBzr to work on 64-bit OS? [01:57] GhostFreeman: is there a bug open ? [01:58] Don't know -- where's the link to the Launchpad page? [01:59] nevermind, found it [02:00] well the real problem is that TortoiseBzr still won't work for me, and I read in the documentation its an issue on only 64-bit systems [02:05] if its in the docs it sounds like the windows guys know about it [02:05] and don't have a fix [et] [02:05] Well, the taskbar responds, but the context menus do not (as in they don't show up at all) [02:06] I'll check on Launchpad and file a bug if I find anything. thanks. [02:06] all I can suggest is that you make sure there is a bug [02:06] Alright [08:57] jelmer: hello, what is missing in order for bzr-svn to support svn:externals ? [12:02] Hi, is this a good usage of set_parent_ids in a test?: [12:02] tree=self.make_branch_and_tree('tree1'); rev1=tree.commit('first'); rev2=tree.commit('second'); tree.set_parent_ids([rev1],allow_leftmost_as_ghost=True); [12:02] With that, I tried to uncommit the second revision [12:24] clemente: I'm not sure why you need the allow_leftmost_as_ghost [12:25] james_w: neither am I, but otherwise it fails: GhostRevisionUnusableHere [12:25] weird [12:26] not sure why rev1 would be a ghost [12:28] It must be due to other things on the test I'm writing. I will continue with it set to False [12:30] Weird; now it works [14:49] Is it possible to have a branch with neither a working tree nor a repository? [14:51] yes [14:55] (e.g. a branch a in a --no-trees repository) [15:53] is using bzr-svn similar in concept to using svk? [15:58] it seems like it is with the biggest difference being that it does not import the entire repository === abentley1 is now known as abentley [16:21] dstanek: yeah, i like bzr-svn, but would like to have support for svn:externals === salimander is now known as irc === irc is now known as Sepheriel [16:39] jfroy|work, yep, please file bugs in launchpad === fta_ is now known as fta [18:33] Hi. I was wondering: what kind of routine maintenance does a Bazaar repository require? [18:35] possibly backups, but nothing else I can think of [18:36] though with the distributed nature of Bazaar, even that isn't as important as for other systems [18:37] LarstiQ: I'm thinking of stuff like "git gc" and "git repack" commands, that you should run every once in a while if you're hosting (particularly a busy) git repo. [18:38] gour: do you know of a good tutorial? [18:38] is there anything similar with Bazaar? [18:38] dstanek: for bzr? [18:39] fynn: hmm, maybe remove the obsolete packs once in a while, although bzr will do that on its own if you do not [18:39] LarstiQ: what's the command to do that in bzr? [18:39] fynn: rm -rf? :) [18:39] gour: bzr-svn [18:40] LarstiQ: of what? :) [18:40] delete the repo, start a fresh one? [18:40] fynn: .bzr/repository/obsolete_packs [18:40] fynn: nah [18:40] OK, I see. [18:40] fynn: but I haven't needed to do that [18:41] basically, I'm trying to determine whether a bzr repo requires more maintenance than a git one. [18:41] fynn: on 'git gc', what exactly does it do? And can you comment on wether needing to run that is related to the git culture of rebasing? [18:41] fynn: ime, there is zero maintenance [18:41] dstanek: well, you just use bzr commands...e.g. bzr checkout instead of svn...i'm not very familiar with svn, but use e.g. bzr branch on svn repo to fetch it etc. [18:41] LarstiQ: I'm a git newbie. from what I understand, 'git gc' removes obsolete packages as well. [18:42] I don't know about rebasing. [18:42] fynn: i do not think about any housekeeping tasks while using git...but i'm scared to even think of using git :-) [18:42] s/using git/using bzr [18:43] fynn: do you maintain a (busy) vcs host? [18:43] gour: what I'm not sure about, is what the lack of stuff like 'git gc' and 'git repack' means. [18:43] dstanek: have you checked http://bazaar-vcs.org/BzrForeignBranches/Subversion [18:43] LarstiQ: I'm considering a migration of a fairly busy SVN repo to a VCS. [18:43] fynn: you have to use git? [18:43] fynn: well as I said, in practice I don't need to do any maintenance. [18:44] gour: I don't have to. I like BZR, and use it to manage my personal projects. [18:44] fynn: oh, maybe `bzr upgrade` once in a while [18:44] fynn: i switched from darcs to bzr and do not look back...bzr is quite robust, simple enough with a friendly community [18:44] but now I need to know whether migrating a large, busy SVN repo should be done to bzr or to git. [18:44] fynn: what do you currently do for svn maintenance? [18:44] nothing. [18:44] fynn: i like bzr's 'safety net' over git complex ui [18:44] ok, that I expect to remain the same then :) [18:45] gour: what do you mean? [18:45] fynn: well, afaik, git allows one to shoot oneself in the foot too easy [18:45] fynn: have you tried bzr-svn ? [18:46] sort of, a few months ago. didn't go very well. [18:46] newer release might be quite better... [18:46] fynn: for my svn repos, I keep backup dumps, and have to restore them once in a while. [18:46] the goal is to migrate the repo, not work with the current svn repo using a different client. [18:47] LarstiQ: I keep backups to, but why do you have to restore? [18:47] fynn: for bzr, that is more offloaded to the users, not the admin running the site. [18:47] fynn: well, i suggest you to take a test-drive with both git and bzr...i'm more than satisfied with bzr [18:47] fynn: fuckups from users basically [18:47] gour: (in fairness, that was with a relatively old bzr [the stable one on Ubunutu Feisty]) [18:47] ahh [18:48] fynn: bzr improves rapidly with recent releases...check announcements and changelogs [18:48] gour: yeah - but that doesn't really tell you how [18:49] gour: my greatest puzzlement is whether the availability of the repack command on git means that: 1) git just gives you an option to optimize and "defrag" your repo, that bzr doesn't provide, OR 2) git repos actually require more care and nurturing than bzr repos. [18:49] dstanek: well, bzr-svn makes it transparent for you to use svn repo - just as you would work with bzr. however you must be familiar with bzr [18:49] gour: this one is better, but i was hoping for something more official - http://tinyurl.com/59j389 [18:49] I suspect it's the former. [18:49] fynn: bzr tends to do it automatically [18:50] LarstiQ: yeah, git does that automatically too, at least the crucial parts. [18:50] fynn: bzr has `bzr pack` btw [18:50] hm, interesting. [18:51] what large, active code repositories are using bzr? [18:51] * LarstiQ hasn't had use for it [18:51] dstanek: ahh...my bzr-svn needs are quite basic for now and i do not intend to fiddle with svn repos more than fetching and possibly doing some simple commits [18:51] fynn: mysql, launchpad [18:52] fynn: there is gnome repo as well (unofficial), emacs... [18:52] fynn: you're aware of the differences in branches/repositories between svn and bzr? [18:52] LarstiQ: (yeah, `git repack` isn't mandatory as well. I've been told that manual repacking might only be deemed important for very large repos, e.g. the Linux kernel. [18:52] fynn: right, that makes sense [18:53] and even then, completely failing to run it manually (thus relying on the automatic `git gc` that runs every once in a while, sort of like how bzr deletes obsolete packages I gather) would only result in: [18:53] 1) the .git dir size being larger than it could be. [18:53] * LarstiQ nods [18:54] 2) performance being not as good as it could be. [18:54] same with bzr [18:54] (very large *and active repos) [18:54] although obsolete_packs don't impact performance [18:54] but joining packs might, I guess that's similar to `git repack` [18:55] yeah, probably. it would be nice to have commands in bzr for joining packs and deleting obsolete_packs. [18:55] fynn: the difference between bzr and svn results in more finely grained branches than svn repositories (where the branch concept doesn't exist as a domain object) [18:56] * gour likes and prefers branch/repo concept [18:57] fynn: `bzr pack` and rm -rf .bzr/repository/obsolete_packs/ . I don't really think the latter warrants a bzr command on its own. [18:58] LarstiQ: ah, so `bzr pack` joins packs? [18:59] fynn: let me figure that out for certain [18:59] fynn: btw, how big is your svn repo? [19:00] LarstiQ: close to 100k commits [19:00] fynn: and it's all 1 project? [19:00] yes. [19:00] ok, that makes it a lot easier at least [19:01] why? [19:01] fynn: 100k on the mainline, or in total? [19:01] i'd say that bzr is made with more up-front design that some other VCSs and now is much easier to tweakk/improve performance..however, when the UI is broken... [19:01] total, but that's mostly trunk. [19:01] fynn: since svn doesn't have the branch concept, it is possible that detangling different projects can be a bit of a pain [19:02] there is some discussion about splitting the project, but that's mostly relevant once we move to a DVCS. [19:02] because yes, the codebase is large. [19:02] * LarstiQ was thinking unrelated projects [19:02] nah, everything in the repo is definitely related. [19:02] fynn: ala the apache svn repo, although those are relatively well seperated [19:03] although there's a possibility that the development team would split, and there'll be a sort of splitting into "sub project" [19:03] fynn: ah [19:04] I'm sure both bzr and git can handle that very well - the question is about performance. [19:04] especially long-term performance. [19:04] maintenance wise, or actually working with it? [19:04] fynn: you know about stacked branches? [19:05] three areas: 1) required routine maintenance, 2) repo size, 3) usage speed [19:05] gour: no, what are those? [19:05] gour: stacked branches solve a particular problem [19:05] gour: we don't know yet what fynn is interested in [19:06] fynn: your needs are a bit different than mine, 1 and 2 are no issue for me, so I'd recommend asking on the list/the people involved with mysql [19:06] like jam [19:06] fynn: see http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar_29.html [19:07] LarstiQ: i was thinking about stacked branched due to possible long history of the project [19:07] something like emacs-project [19:07] fynn: on usage speed, git is faster on most operations, you will have to see if bzr is fast enough for you (it is for me) and which particular use cases are important to you. [19:08] gour: yes, that might help for the initial-branching-speed for users, but not so much for an admin [19:08] LarstiQ: cool. I'm interested in 2 mainly because we have quite a few developers, some of them switching machines and pulling the trunk over poor and/or wireless connections. [19:09] fynn: ok, for those cases gour is right, stacked branches don't require to have the full history present [19:09] so if bzr repos are almost 3 times larger than git repos (which some benchmarks suggest), that could have a significant impact on them. [19:09] fynn: with 100k commits, that can significantly cut down in download size. [19:09] *nod* [19:09] (and disk space, but that's not the main problem here) [19:10] usage speed is the least of my concerns (which is why I listed it last). [19:10] fynn: it really depends on what the benchmark is looking at and when, bzr and git have been bigger and smaller than each other through history [19:11] it's mainly because now that we're moving to an advanced DVCS, some of the developers are thinking about new refactoring / code-mining practices that could be performance-intensive. [19:11] fynn: right [19:12] usability-wise, bzr is the most convenient of all DVCSes that I used so far. [19:12] i know that e.g. for ghc evaluation someone didn't use shared repo, so it ended up comparing apples & oranges [19:12] gour: right [19:12] * gour likes darcs as well, but stability...hmm [19:13] fynn: in bzr terms, a repository is a storage place for revisions. More than one branch can share the same repository, storing each common revision only once. [19:13] it really allows me to do anything I need, I'm extremely pleased with it, and use it for all my personal projects. the only reason I brought up git is because it's not a personal project, and stuff like performance or maintenance overhead will affect others besides me. [19:13] fynn: this is obviously easier on disk space, but it also makes branching within the repo cheap, you don't have to copy all that data around [19:14] * LarstiQ nods at fynn [19:14] fynn: is the project public? [19:14] gour: (didn't the GHC evaluation also talk about git flexibility features that hg/bzr lacked, for example history rewriting? [19:14] LarstiQ: unfortunately, not ATM :) [19:15] we may be able to release some of it (especially if we manage to split out some of the sub-projects, using git/bzr) [19:15] fynn: ok [19:15] fynn: if you check that wiki page on GHC tracker and ml, bzr was ruled out due to speed only based on dubios benchmarksmrks :-/ [19:15] fynn: well, then I won't give it a quick peek with bzr-svn right now :) [19:16] fynn: I'm happy to assist you further with this though [19:16] but I need to get myself some dinner first [19:16] fynn: history rewriting and git's rebase is mostly not required with bzr [19:16] LarstiQ: thanks. my next step is to import our massive SVN to both bzr and git, and run some benchmarks on the resulting branches. [19:16] LarstiQ: bon appetite! [19:17] gour: hmm, could you elaborate? [19:17] fynn: read http://andrew.puzzling.org/diary/2008/July/29/rebase-criticism [19:18] fynn: there is a bzr rebase, and it is useful in certain situations, but in general the bzr culture tends to frown at the level of history destructive operations common with git [19:18] ;) [19:20] * gour is reading learning-python-3e in order to be able to hack on django/pinax/.../maybe bzr in the future [19:21] heh, "The current stable version is 1.8, released November 17th, 2008." [19:22] where did you find it? site says: Bazaar 1.8 was released on the 16th of October, 2008. [19:22] http://bazaar-vcs.org/Download [19:23] so, no need to worry about the future :-) [19:24] the future is here. [19:25] gour: btw, I'd just read the Python tutorial [19:25] ohh, you're also new ;) [19:25] do you have any previous programming experience? [19:25] no, actually :) [19:25] I'm saying, if you have experience, reading the entire "Learning Python" is a waste of time imho. [19:26] yep...from fortran to C(++)...but didn't do any programming for many years and then became interested for haskell [19:26] OK, see, the tutorial will get you up to speed with Python in the fastest way. [19:26] heh, learning python is really slow, but it covers 2.5 with insight into 2.6 & 3.0 [19:27] i like books for 'offline reading' when i'm afk :-) [19:28] i'm at the last part - exceptions... [20:04] fynn: ah thanks, I fixed the release from the future. [20:08] LarstiQ: cool. [20:47] hi. i have a bzr 101 question. I messed up a bzr send and now it seems to think i'm rooted at /path/to/branch/address@mail.com. how do i fix that? [20:48] aidans, what do you mean it thinks your rooted? [20:48] bzr bundle complains with bzr: ERROR: not a branch "/path/to/branch/address@mail.com" [20:49] beuno: FWIW, there's a new version of MooTools out. You should update the copy in Loggerhead. [20:49] aidans, you can do: bzr send ../branch [20:49] Peng_, I have a better idea for that [20:50] I'm at the airport, waiting to get on a plane to London with all the rest of the lp devs [20:50] ah. thanks. :) any idea how to fix the confusion it's suffering? [20:51] and we're going to switch it over to YUI, rockstar is going to improve performance, and, hopefuly quite a lot of other improvements will get done in the next 2 weeks :) [20:51] beuno: Heh, that works too. :) [20:51] 2 weeks of sprinting? [20:51] aidans, take a peak in ~/.bazaar/locations.conf [20:51] Peng_, :) [20:52] LarstiQ, yes. "Epic Sprint" [20:52] beuno: okay :) [20:52] lot's of new shiny things coming, we need to prepare! [20:52] lots even [20:53] beuno: i don't have that file, or anything similar under .bzr in the brnach [20:53] aidans, right, it's in your home dir [20:53] hey beuno [20:53] hey LarstiQ [20:53] aidans: "bzr info" to check what's wrong, bzr pull/push/merge --remember the_right_path to fix it. [20:53] how you doing? [20:53] /home/username/.bazaar/locations.conf [20:53] aidans: Or edit .bzr/branch.conf or ~/.bazaar/locations.conf. [20:53] hey hey james_w [20:53] pretty good [20:53] bored in an airport [20:54] how are you? [20:54] you always seem to be flying at the moment :-) [20:54] beuno: i know, i only have bazaar.conf and ignore in ~/.bazaar [20:54] good thanks [20:54] aidans, ah, then what Peng_ said :) [20:55] james_w, heh, yeah. I kinda get that feeling as well :) [20:55] I'm off for a month now [20:55] woha [20:55] are you holidaying post-epic? [20:55] I wish [20:55] more sprints [20:55] Montreal [20:55] heh :-) [20:56] Peng: --remember sorted it. pull had the right place, but merge didn't and that seems to have fixed send. thanks! [20:56] I'm just hanging out in madrid for the week in between, so I don't rack up so many miles :) [20:56] ...Or actually "bzr send --remember". [20:56] aidans: :) [20:56] editing the index files by hand was unappealing ;) [20:59] Err, I meant .bzr/branch/branch.conf. [20:59] Anyway.. [21:01] s'all fixed now :) [21:32] aidans, the bug you reported [21:32] it's because you aren't specifying the revid [21:32] you're giving it a revno [21:32] of course, it shouldn't traceback, so the bug still holds [21:37] hello. I wan to cnovert a svn repo to a bzr one. I found svn2bzr, and it seems fine... in the papers. the link to the code is dead. which is agood way to do it? [21:43] StyXman: I'd either use bzr-svn or something based on fast-export/import [22:11] I can't branch a shared repo, can I? [22:11] not the whole repo, no [22:11] you can branch branches [22:11] or, just cp the whole repo [22:11] ajá, so I co a branch from the repo and then barnch it? [22:12] you can branch the branch :) [22:13] I meant, I chechout a branch and then branch the branch, is that it? [22:14] why don't you just branch the branch> [22:14] ? [22:14] beuno: because I don't have one [22:15] I just used bzr-svn to convert a svn repo, and I think I got a bzr repo [22:15] then what are you talking about doing a checkout from? [22:15] OH [22:15] SVN [22:15] ignore me [22:15] * beuno defers to LarstiQ [22:17] i got a dir with a .bzr dir in it [22:17] ok [22:17] if I run bzr info, it says it's a shared repo [22:17] I can do that [22:17] and now? [22:17] and you want to see the actual files? [22:17] create a working tree? [22:18] hmm, create something in it so I can... ah [22:18] yes, in the end I would like the files [22:18] try running 'bzr co' in there [22:18] ok, I think I'll re-read the concepts [22:18] * LarstiQ blinks [22:19] StyXman: how did you get a shared repo from bzr-svn? [22:19] LarstiQ: dunno, I just found a conversion I did several months ago :| [22:20] but I think what I want is a bzr init [22:20] StyXman: what I would probably do, install bzr-svn, then 'bzr branch path/to/svn/repo' and get a bzr branch out of it [22:20] no, it's not that [22:20] ok [22:20] StyXman: then you'll need to fill me in on what the problem is :) [22:21] I mean, it's not bzr init [22:21] StyXman: what are you trying to do? [22:21] I want to completely convert the svn repo in a bzr one, and then get rid of the svn one [22:21] then take this bzr repo, put it in my server, branch away from it, and keep hacking [22:22] StyXman: right. I'd personally still try first branching with bzr-svn as I said. [22:22] I think i got the first step [22:22] hmm [22:23] StyXman: then, if you're happy with that, you could import all the branches from the svn repo with `bzr svn-import` [22:23] so branching from the (svn?) repo would give me a bzr brach (with its own repo)? [22:23] StyXman: yes [22:23] wow [22:23] StyXman: that is [22:23] that's some magic, not the one I spected [22:23] StyXman: the branching will work as normal bzr branching [22:24] StyXman: if the location you are branching to doesn't have a repository, it will create a standalone branch (which has its own repository) [22:24] hmm, I remember something about lightwieight branching not having repos... [22:24] StyXman: and if you are branching into a shared repository, it will use that instead. [22:24] StyXman: lightweight checkouts [22:24] StyXman: but you don't deal with those if you use `bzr branch` [22:24] into? do I branch *into* a shared repo? [22:25] StyXman: sure. My ~/src/bzr/ is a shared repo, with the branches bzr.dev, nested-trees, 1.5, 1.8 etc within [22:25] hmm [22:25] nested trees! [22:25] :) [22:25] StyXman: a shared repository is just a storage place for revisions, nothing more. [22:25] beuno: yes! indeed! [22:26] LarstiQ: yah, that one I got :-P [22:26] StyXman: ok :P [22:26] LarstiQ, have you done more work on making the diff smaller? [22:27] so when you sya 'into', you mean 'in a directory "below" the one holding the shared repo'? [22:27] say* [22:27] StyXman: so, when I do 'cd ~/src/bzr; bzr branch lp:bzr' I get ~/src/bzr/bzr, a new branch, which uses ~/src/bzr as its repository. That action we call branching into a repository. [22:27] StyXman: correct. [22:27] beuno: no :( [22:27] lp:? [22:29] StyXman: lp: is a prefix that will look on launchpad for the branch [22:29] che, te jodo para hacerte unas preguntitas de los tracs que dan [22:29] oup, wrong paste [22:29] bzr: ERROR: Not a branch: "/home/mdione/src/projects/psync/bzr/.bzr/branch/". [22:29] StyXman: so lp:bzr expands to http://bazaar.launchpad.net/~bzr/bzr/trunk/ [22:30] StyXman: this occurs when you're doing what exactly? [22:30] StyXman: something is not a branch :) [22:30] bzr branch . in the shared repo [22:30] `bzr branch .` ? [22:30] (and I thought I got it right...) [22:31] StyXman: branch requires an argument for where to branch _from_. And optionally takes an argument where to branch _to_ [22:31] StyXman: did you tell it to branch from '.'? In that case, is '.' a branch, or is it not? [22:32] no, it's teh shared repo [22:32] let me read a little more, see if i can get it [22:38] ok, so what I got whas several barnches (trunk, branches/*, tags/*) with a repo shared between them [22:38] O i should move everythong to the server and branch from the trunk branch [22:38] so I* [22:39] StyXman: that's an option, yes [22:42] nice! [22:42] \o/ [23:35] i do find it a bit hard to read the thread on hudson on the list without wtfing a bit [23:40] because you're not the brother of a Java application? [23:40] yeah [23:41] zachera@apollo:~$ bzr branch aristaeus/ [23:41] bzr: ERROR: Not a branch: "/home/zachera/aristaeus/". [23:41] what'd i do wrong [23:41] zachera: aristaeus does not seem to be a branch. You think it should be? [23:41] hm, i think i figured it out [23:41] did bzr init [23:41] then bzr add [23:41] lol [23:42] * LarstiQ blinks [23:42] how do i delete the SVN repo for this aristaeus folder [23:42] i want to start it over [23:42] >_> [23:42] zachera: svn repo? [23:42] repository [23:42] how do i remove all the .svn folders out of aristaeus [23:42] zachera: do you mean bzr? [23:42] zachera: this is #bzr, not #svn [23:43] . [23:43] zachera: maybe you can provide some more context so I actually get what is going on. [23:44] okay [23:44] do i do bzr init outside of aristaeus or within [23:46] LarstiQ: ^ [23:46] Hi I am getting TypeError: object.__init__() takes no parameters after I upgraded to python 2.6 with bzr 1.6.1 .. is bzr 1.8 enough to work with python 2.6 ? [23:46] zachera: if aristaeus is a project you'd like to make a bzr branch out of, then within [23:47] screw the whole branch thing [23:47] aristaeus is the folder which contains the project [23:47] i want to make the files within the aristaeus a part of the SVN repository [23:48] zachera: what do you mean with "SVN repository"? Specifically a Subversion repository, or are you using "SVN" as a general term for version control systems, and actually want to do something with Bazaar? [23:49] ok [23:49]