[00:01] spiv, hello [00:01] spiv, lifeless, igc, jam, call in a sec [00:05] 'morning spiv, poolie [00:05] how should I figure out what the parent revisions of an existing file text revision are? [00:06] CommitBuilder.record_entry_contents() doesn't take any text_parents arguments [00:14] lifeless: ^ [00:21] abentley: how come I have to do 'bzr up' rather than 'bzr co' in the branches that export-loom makes? [00:22] jelmer: it assigns the value itself [00:23] lifeless: what if the text wasn't changed but inherited [00:23] ? [00:23] it may or may not assign a new one based on the per file graph [00:23] hello jelmer, lifeless [00:24] spiv, oh well that was probably a good place to wrap up [00:24] what's the goal here, reimplementing this, or using it ? [00:24] * jml waves [00:24] good luck [00:24] poolie: :) [00:24] lifeless: but there's no way for CommitBuilder to figure out what the parents of a text are when recording an existing text [00:24] jelmer: it has the parent trees as state [00:24] jelmer: read the code :P [00:24] lifeless, The parents of the text I mean [00:24] lifeless: If you commit a merge for example and the merged revision is a ghost [00:25] lifeless, and one of the texts wasn't changed [00:25] then it cannot calculate it correctly because the ghost data is absent [00:25] lifeless, is there no way to determine what the parents of the text are? [00:25] so it calculates it based on the available data [00:25] jelmer: you keep repeating this, but I'm really not understanding if you are asking a question, making an assertion, or seeking help solving a problem [00:25] all three [00:25] the statment doesn't make sense to me [00:26] perhaps you could unpack whats going on so I'm not guessing at quite so much at once [00:26] So, let me start by explaining the issue I'm trying to solve [00:27] bzr-svn needs to make sure that the parents recorded for a text revision are correct [00:27] generally, it will induce the parents for a specific text from the information in svn [00:28] if that doesn't help, it'll look a specific svn property [00:34] lifeless, Never mind, I just answered my own question [00:34] :P [00:34] jelmer: so commit builder has enough state to look in each inventory that is available to determine the files presence, and last-changed, in that inventory [00:35] jelmer: doing a commit with ghosts should never happen except for an importer from tla [00:35] ghosting is something that happens deliberately, after revisions are created, not adhoc [00:35] lifeless: The thing is, bzr-svn uses the commit code also when pushing [00:35] jelmer: when pushing, there should be no ghosts though [00:35] lifeless: There can be - when pushing into svn you're not necessarily pushing merged revisions as well [00:36] also, there is a hole in our ghost support infrastructure; a last-changed value in an inventory which is the value of a ghost will cause checkout/export to fail [00:36] yes, several people have hit that using bzr-svn [00:36] yah [00:37] back shortly, food calls [00:37] spiv: please let me know if my branch hook patch was sufficient unto the tests [00:38] lifeless: I'll take a look now [00:38] lifeless: thanks for playing soundboard (hope that's a correct translation) [00:41] jelmer: sounding board is probably more common, but soundboard is totally understandable :P [00:42] lifeless: looks ok to me. I can't think of any other worthwhile unit tests to add. [00:43] spiv: well, its approved once trunk unfreezes [00:43] spiv: I was more meaning 'does it do what you need' [00:49] lifeless: Oh I see. Yes, I think so. [01:02] right, its now yours, enjoy. [01:03] * LaserJock crosses his fingers [01:03] darn [01:03] lifeless: james_w set me up with a little hacky script to import both debian and ubuntu source packages [01:04] I got one to work fine [01:04] but 2 have died [01:04] ah, hi LaserJock [01:05] hi mwhudson [01:05] LaserJock: i didn't do anything about the matplotlib vs python2.4-matplotlib thing [01:05] oh? [01:05] LaserJock: i just confused about what the right thing would be [01:05] LaserJock: oh, shame. [01:06] oh, wrong channel [01:06] except you're not in #launchpad :) [01:06] mwhudson: I'll join #launchpad [01:09] lifeless: well, it would be fun if it just worked without any problems [01:09] lifeless: but it looks like I might be able to help debug bzr-builddeb [01:09] so that's good anyway :-) [01:13] LaserJock: cool [01:14] * markh cheers lifeless on his review-athon :) [01:17] oops [01:17] 95 % of the memory usage of bzr-svn appears to be in reading ~/.subversion/config [01:19] jelmer: That's with respect to the crazy "eat 1GB of ram on multi-pull" bug? [01:19] RAOF: Yep [01:20] jelmer: whee! [01:20] * RAOF wonders how one can blow 1gb resident on reading a config file :) [01:20] it's parsing ~/.subversion/ for reading every file multi-pull tries to open [01:20] and multi-pull tries to open a lot of files [01:20] Aaah. And no GC gets done? [01:24] RAOF, Nope [01:25] RAOF, Ok, that fixes it.. [01:26] lifeless: in the abspath mail you said to add a test that "sets sys.platform to something windows" - can you please elaborate? [01:26] did you mean *checks*? [01:27] anybody got an idea of what http://paste.ubuntu.com/44717/ means? [01:27] it looks like it's trying to make a path with non-ASCII characters [01:28] LaserJock: or possibly even any parent being non-ascii [01:29] is that anywhere in the bzr branch? [01:29] or does that just apply to the root directory of the branch [01:30] markh: no, I mean sets [01:30] markh: you have conditional code based on the platform right? [01:31] so set sys.platform for the benefit of other platforms to be able to test it? [01:31] yay bubba :) [01:31] markh: set sys.platform so that other platforms test that case, yes. [01:31] heh - I'd figured that might be a dangerous thing to do, but OK... [01:32] markh: look for sys.platform in the osutils tests [01:32] will do, thx [01:32] probably can be cleaner than that is, but its an example [01:33] * markh goes to wait in line for an hour at the chinese embassy... [01:34] markh: off to china? [01:34] yeah - brother getting married there next month! [01:35] I was actually visiting him there earlier this year - quite amazing - but you really need someone who speaks the language close by :) [01:35] (which he does) [01:43] markh: does he *read* the language? === Spaz is now known as Kittens [02:48] markh: when you get back, I have a branch I'd appreciate your testing [02:51] a7p: still around? [02:55] jep [02:55] but I won't last more than another 30 minutes [02:55] ok [02:56] I'll make it short enough :) [02:56] a7p: I can't reproduce the crash, also I don't see any related error in the log [02:56] a7p: could you check ~/Library/logs/Java? [02:56] * a7p starts up a terminal [02:57] if the jvm crashed, there should be a log there [02:58] jep, got a couple of eclipse-crashfiles here [02:59] should I attach one to the bug? [02:59] a7p: please :) [03:01] Verterok: done [03:02] thanks! I'll keep digging [03:04] * a7p keeps supplying useless treasuremaps [03:11] a7p: not so useless :) [03:12] ;) [03:12] a7p: it seems like a bug was fixed in Eclipse 3.3 [03:13] would be pritty bad, if they only introduced new ones... *g* [03:13] a7p: http://lists.apple.com/archives/Java-dev/2007/Nov/msg00014.html [03:15] a7p: sorry, "it seems that a similar bug was fixed in 3.3" [03:16] looks, pretty much like my problem. [03:20] a7p: the widget used in the commit dialog will be replaced, pretty soon. it's a work in progress [03:21] wounderful, nice to hear [03:21] if i understood correctly, this is a osx 10.5 issue - other platforms won't suffer from it. [03:22] I'll try to rollout a new build as soon as possible [03:27] * a7p looks happily forward to it - Thanks Verterok, that's Bugreporting the way I like it. [03:27] and now I'm going to put my tired head to rest [03:29] fooding [04:14] I should just try this myself, but what does Bazaar do if, when using HTTP, a /.bzr/ directory redirects somewhere else? [04:14] * Peng_ tries it himself. [04:19] spiv: http://marc.info/?l=linux-netdev&m=122091500114869&w=2 [04:21] spiv: details on why coalescing the bytes written to the socket helped [04:23] Oh, good, it works. [04:24] lifeless: that's a nice clear description of things [04:25] lifeless: It's a pity I learned that stuff the hard way rather than by reading about it :) [04:25] Is there a pdf version of the html guide? [04:25] http://doc.bazaar-vcs.org/latest/en/user-guide/index.html [04:25] ? [04:27] Peng_: you can redirect a branch, redirecting a repository is likely to die horribly [04:28] jml: apparently well enough to read signs and stumble through things, but not well enough to comfortably read a newspaper for example [04:28] lifeless: how can I help? [04:28] markh: test my patch [04:28] which one? :) [04:28] the one I cc'd to you [04:28] that prominently asks for help :P [04:28] _walkdirs [04:28] oh :) [04:29] markh: when I visited, I found the inability to read the language much more frustrating than being unable to speak it. [04:30] jml: I doubt we would have survived ordering in some of the places we ate at, for example. We would have ended up having a much more "westerners" experience I think [04:31] I remember once thinking "surely I can order a coffee" - and failed misterably :) [04:32] the "coffee" part was understood, but trying to explain I wanted it to take away was a sticking point :) [04:32] just get it, then walk out the door [04:33] yeah, and just keep walking :) [04:33] well no, stop and let them change it around now they get the message :P [04:37] lifeless: Well, I'm redirecting both the branch and repo (from /foo/... to /bar/...). Hopefully it'll be okay. [04:39] lifeless: BTW, this is very trivial, but I think bzr-search's cmd_index wastes a transport. It opens one, and then passes the URL to index_url, which opens it again. [04:39] Peng_: patches appreciated :P [04:41] lifeless: Heh. But what should I change it to do? Make index_url accept a transport? Rename index_url to index_transport or something? === ajaksu is now known as ajaksu_away [04:46] Peng_: I think there is a transport taking helper already [04:47] Peng_: if there isn't, split the current one in two, and call the helper [04:54] lifeless: is there a subset of the tests I can specify? Otherwise things get lost in the noise... [04:54] ./bzr selftest --no-plugins osutils win32 walkdirs [04:55] File "O:\src\bazaar\bzr\bzr.lifeless\bzrlib\tests\branch_implementations\test_parent.py", line 95, in test_win32_set_parent_on_another_drive [04:55] base_url = b.abspath('.') [04:55] AttributeError: 'BzrBranch6' object has no attribute 'abspath' [04:56] x7 times [04:56] heh [04:56] well thats unrelated :P [04:59] anyone know a way of using bzr on an svn project, but with local storage but not the whole history? [04:59] lifeless: they are the only errors [05:00] Hmm, I think it winds up opening the branch twice too. [05:01] markh: cool [05:01] markh: care to review it ? :) [05:01] having a quick look now [05:01] uniscript: branch --stacked [05:02] but the docs say that that's just a light checkout or am I reading it wrong? [05:02] i.e. can I branch, ci merge etc. with such a branch locally with no access to the svn repo? [05:03] and then just push / merge upstream later? [05:05] hrmph - I'm not testing much as I haven't run a build [05:06] things are a little uglier when I do :( [05:08] lifeless: http://pastebin.com/m27ccab4c [05:10] markh: could you fix? [05:10] markh: the intent should be pretty obvious [05:10] not today :( [05:10] sure [05:11] No windows dev environment here at the moment, so I can't [05:11] np [05:11] uniscript: no, no-access requires full history copied, today. [05:11] OK thanks, at least I know not to go chasing after the wind :) [05:12] uniscript: partial-local-storage is what you asked for :P, sorry that its not enough [05:12] you say "today" is it in the pipeline? [05:12] long term plans, nothing to hold breath over :) [05:13] I can imagine that people would like to join an svn repo from some revision onwards [05:13] Or I suppose it can be part of the ability to consolidate bzr repos [05:13] does that exist? [05:13] I'm not sure what you mean [05:13] clear out irrelevant history? [05:14] say I have 1000 revisions in my repo [05:14] and I don't want all that history kept, can I say merge 200-300 as one revision and dump all that history? [05:15] Wait, it's just a one-line change to fix this. [05:16] Well, that's to stop it from wasting one transport. There are others too. [05:21] lifeless: Do you mind if I pass "foo/" to index_url instead of an URL like "file:///path/to/foo/" or whatever? [05:29] Peng_: for testing? [05:41] bug 248275 [05:41] Launchpad bug 248275 in bzr "Crash when pulling with --no-plugins" [Undecided,Fix released] https://launchpad.net/bugs/248275 [05:41] poolie: ^ is that a bubba alias? [05:42] i think it's probably a different mentally ill person [05:44] lifeless: No, because it's the least-invasive way to get rid of that wasted transport (it's just used like get_transport(url).base) [05:45] Peng_: oh. well foo/ isn't a url, its a url fragment or possibly a unicode path [05:45] I'd rather not pass paths to url functions, bad things tend to eventually happen [05:47] ok [07:01] good morning bazaar ! [07:18] man I hate libc maintainers sometimes [07:19] st_mtime is a def __get__(self): [07:19] return self._mtime [07:19] bad paste sorry [07:19] st_mtime is a defined macro from bits/stat.h now :( [07:27] ok [07:27] 10% shaving by using a compiled stat object === mark1 is now known as markh [08:21] hi, I [08:21] 've got a question: I've got a checkout and did a "bzr ci --local" yesterday. Today I did a "bzr up" and now my local commit from yesterday shows up as a pending merge. Is there any way to get to the previous state where my local commit just will be committed with the next "bzr ci"? without in fact doing a merge? [08:22] (for the case my last sentence got cut): Is there any way to get to the previous state where my local commit just will be committed with the next "bzr ci"? without in fact doing a merge? [08:23] and what effects does a "bzr update" have on the local repository if it contains local commits? [08:26] jonnydee: (Your last sentence didn't get cut. IRC's line length limit is closer to 500 chars, and many/most IRC clients handle it sensibly.) [08:28] jonnydee: Sorry, but I don't have experience with checkouts, so I can't really answer your question. [08:28] Peng_: ok thanks for your feedback [08:29] it's a lightweight checkout? [08:29] no, a normal checkout [08:29] does it make any difference? [08:29] (in my case) [08:31] jonnydee: My wild guess would be that you can't avoid a merge, because it would require rebasing, and bzr isn't big on that. [08:31] But I don't know the mechanics of local commits in checkouts, so that may be wrong. [08:33] probably you are right... So I'll do a merge... Thanks a lot for your help :) [08:39] lifeless: you raiding tonight? [08:49] bzr diff -r date:2008-09-09,09:00:00 [08:49] doesn't seem to work [08:49] any suggestions? [08:55] sabdfl: bzr diff -r date:2008-09-09T09:00:00 [08:55] sabdfl: seems to work ok for me [08:56] with a comma it works for me as well [08:56] ./bzr diff -r date:2008-09-09TO09:00:00 ~/software/bzr.dev [08:56] bzr: ERROR: Requested revision: u'date:2008-09-09TO09:00:00' does not exist in branch: BzrBranch7('file:///home/mark/software/bzr.dev/') [08:56] TO? [08:56] sabdfl: it's a 0, not O [08:56] sabdfl: There probably isn't a revison after that time, hence the "no such revision" error. [08:56] but with comma it works fine for me as well, as I said [08:57] doh [08:57] I don't think there's been any commits to bzr.dev since 2008-09-08 07:18:35 +0100 [08:57] yeah, I get it with dates in the future as well [08:58] but the error message is at the very least misleading [08:58] (And "-r date:..." calculates using your local timezone, so comparing is often confusing....) [08:58] Yeah, the error message could definitely be better. [08:59] and different output for "no commits since that time to compare to" and "no commits at or after that time at all" === fta_ is now known as fta [10:04] jml: shutdown night [11:45] lifeless: So.. I mailed the mailing list about my "log" range ideas... no response.. :/ [11:54] Hi all.. I've made a little mess, by inadvertently deleting a branch from a repo. I have the branch pushed-to in launchpad, is there a way to recover the branch in my repo without branching and merging again? Thanks [11:56] kinkie: if you branch it again, it will (re)use the revisions from your local repo, so it's cheap [11:56] kinkie: bzr heads --all will show all tips in your repo [11:56] And uws is also correct [11:57] awilkins: What is the difference between "dead" and "alive" heads? [11:57] My way is tricksier but requires no network connection ; his way is easy and requires minimal network [11:57] uws: "Dead" heads are ones that are not in a branch [11:57] awilkins: well, if you ask on irc i assume a network connection is available ;) [11:58] awilkins: how does it know? [11:58] uws: I presume it recurses, but I'm not sure. [11:58] uws: I'm going to try it now :-) [11:58] * awilkins randomly deletes a branch [11:59] Yup, dead heads are ones with no branch, but still listed by all [11:59] awilkins: it can't know if I have branches somewhere on my machine (or on another machine) that are on that specfic head, right? [11:59] e.g. a checkout on another machine [11:59] eh, s/checkout/branch/ [11:59] uws: I think it restricts itself to branches within that repo [11:59] ah, that makes sense (common setup anyway) [12:00] Probably very wuick in a no-trees repo [12:00] awilkins: ok, I found the head. What then? (I'm not so big on bzr recoveries yet ;) [12:00] Pretty quick in a trees repo too ; it only has to check .bzr folders [12:00] trunk is 'trunk' [12:00] let's call the branch 'foo' [12:01] You should be able to branch it from the listed revid: [12:01] should I just 'bzr branch trunk foo'? And as long as the name matches, it'll just revive the branch? [12:01] bzr branch trunk -r revid: foo ? [12:02] awilkins: heads --all shows me a bunch of revisions that have been committed/merged into my branch ages ago. how come? [12:02] uws: because they're all tips of branches that no longer exist in your repo [12:03] uws: I suspect if you branch your trunk into another repo and try again they'll disappear [12:04] awilkins: I still don't know how it figures that out [12:05] uws: The help says "revisions without descendants" [12:05] awilkins: yeah, but they're merged, so they have revisions on top of them [12:06] awilkins: that did it. THANKS A LOT! [12:06] awilkins: (but indeed, creating a new repo makes them disappear_) [12:06] There may be more to it than meets the eye then [12:07] kinkie: Thanks for helping me practice that, never done it before [12:08] I honestly hope it's an one-shot affair ;-) [12:09] kinkie: I had a small doubt that it might not work with a revision that was never merged into the branch I'm instructing it to branch, but I just tried it and that works just fine [12:11] awilkins: hmmmm. it could be that revisions I've uncommitted show up as heads [12:11] uws: Aha, yes, I think you've put your finger on it [12:12] awilkins: I was triggered by the exceptionally high number of typos in the commit messages :) [12:15] maybe I am too stupid, but somehow bzr commit -x does not exclude anything. [12:56] night all [14:40] Leonidas: it works for me, but it doesn't affect the diff shown by --show-diff, which I will file a bug on, is that all you were looking at, or did you look at the committed diff? [14:41] james_w: when I committed it has included the file in the output, so I think it has committed it as well. I did an uncommit, but I'll test it again when I find some time to make sure it is not because I'm too stupid to use it. [14:42] Leonidas: I saw it was in the diff, but not the "modified foo" lines it prints, and "bzr diff -c -1" afterwards shows only the changes that I wanted [14:50] bug 268135 [14:50] Launchpad bug 268135 in bzr "bzr commit -x doesn't change the --show-diff output" [Undecided,New] https://launchpad.net/bugs/268135 === mvo__ is now known as mvo [16:02] that's not good: "branch.lock_read()" deleting the branch, there's something fishy going on here [16:04] I was just messing around because of the slow startup thread on the mailing list, I ran "bzr revert" on a single file, and it took like 5 seconds. :( [16:04] ah no, just me being stupid it seems [16:04] Stupid hard drives. [16:23] I have a problem with code I am writing [16:24] it does "revid = tree.commit()" and then "other_branch.fetch(tree.branch, last_revision=revid)" [16:25] this works fine when the branches are in separate repositories, but fails when they share one [16:25] as the fetch detects that it is fetching to the same repo, and just checks that the last_revision is present [16:26] this check is what fails [16:26] if I use pdb to pause just before the fetch "bzr log" and "bzr heads" from another process outside can see the revision in question [16:27] do I need to do something to make the current process see the just committed revision, or am I missing something else? [16:27] morning all [16:27] is there a way to remove a project from bazaar? to unregister it? [16:29] foebrian: Why do you want to? [16:29] hi Odd_Bloke [16:30] james_w: o/ [16:31] Odd_Bloke: how's the job? [16:31] Odd_Bloke: well i setup bazaar on my home server, and missedtyped the project path, so now 6 projects are considdered one, so i want to unregister it, then fix by adding just one project. if that make sense [16:31] james_w: Not bad. [16:32] Currently work on OO.o. D: [16:33] foebrian: What do you mean by 'projects'? [16:34] Odd_Bloke: well i have a single project folder /storage/projects then below that i have my project 'branches' like /project1 /project2 /project3, so now all the folders are commited to one 'branch' even though they are seprate projects [16:35] does that make sense? [16:36] foebrian: Right, move /storage/projects/.bzr to somewhere else (just as a backup), and then 'bzr init' in each of the separate project directories. [16:36] If the projects are related, you should consider running 'bzr init-repo /storage/projects' beforehand, it'll save space. [16:37] Odd_Bloke: so the removal of .bzr will remove it then? unfornately they are not related, seprated things [16:38] foebrian: Yeah. [16:42] Odd_Bloke: awesome, it worked! thanks Odd_Bloke! [16:42] chaos is removed! [16:42] bug 264705 if anyone has any ideas about my problem [16:42] Launchpad bug 264705 in bzr-builddeb "merge-upstream fails when shared repository is present" [Critical,New] https://launchpad.net/bugs/264705 [16:43] foebrian: No worries. [16:48] james_w: Are you still working on versioning all of Ubuntu? [16:49] Odd_Bloke: yup [16:49] james_w: How's it going? [16:50] Odd_Bloke: it's coming along, spending a week or two bug fixing at the moment before Ubuntu beta freeze, and then back to importing and documentation [16:50] james_w: Ah, cool. [17:00] By the way guys: I've just built myself a WinXP VM in VirtualBox. First thing I did was installed Bazaar, which has TortoiseBZR. I'd like to report it JustWorks. It's lovely ;) [17:01] * kinkie is away: see you later/tomorrow [17:04] kinkie: If you could disable away messages, for this channel at least, that would be appreciated. :) === kiko is now known as kiko-fud [17:53] lifeless: ping me when you wake up, I need you to make a 1.7 branch so I can do 1.7rc1 [18:03] * justizin wonders why the OSX 10.5 installer is an older version of bzr (1.5) than the OSX 10.4 installer (1.6) [18:03] does the 10.4/1.6 not work on leopard? [18:11] justizin: the installers are builded by the community [18:11] fair enough :) [18:11] looks like 1.6 installer wants python 2.5 on 10.4, complains i need python 2.5 even though i have it on leopard [18:11] justizin: I build the 10.4, and 'ld like to build the 10.5 too, but no leopard nor mac-intel here :( [18:12] Verterok: can i run the build for you? ;) [18:12] i've got three intel macs here running leopard. [18:12] justizin: the 10.4 installer depends on a user installed python. 10.4 only provides python2.3 by default [18:12] love to help.. [18:12] yeah i figure as much.. [18:13] how does the checking work? [18:13] seems it should be possible to look for python in /System/Library/Frameworks as well as /Library/Frameworks or ~/Library/Frameworks... [18:13] justizin: let me check [18:13] but i know this is a challenge for many mac / python installers.. [18:13] np [18:14] 1.5 will serve my needs for now but i'd love to help make available better installers for mac any way i can. [18:14] justizin: the 10.4 installer checks CFBundleShortVersionString property in /Library/Frameworks/Python.framework/Versions/2.5/Resources/Info.plist [18:15] is it possible to configure alternative checks, or does it only allow one location to provide a dependency? [18:16] justizin: I think it's possible, but I dont' know if its going to work [18:16] hm [18:16] is source for the installer accessible? [18:16] justizin: all the C extensions are compliled against 10.4 dynlibs [18:17] fair enough [18:17] i suppose we can just port it to 10.5 [18:17] justizin: I think phanatic builds the 10.5 installer, and have all the required bits [18:18] justizin: check Issues section at http://bazaar-vcs.org/MacOSXBundle [18:18] got it [18:22] in eclipse using bzr-eclipse I've found that if I check out my work into a subfolder of the project (for example, trunk) then eclipse doesn't recognize the project as being managed by vcs. Does anyone know a workaround? [18:23] justizin: if you don't have a reply, please let me know and I'll push my installer branch to some public location [18:23] newz2000: Eclipse only support project level team provider mappings [18:23] oh, too bad [18:24] newz2000: what is the layout you need? [18:24] Verterok: i'd like if you published it.. [18:25] justizin: at your service ;) http://verterok.com.ar/code/bundle-10.4/ [18:25] well, I was taught an interesting way to manage my project... create a folder, keep my main trunk branch in a sub-folder, and when I'm fixing problems create a branch for the fix and work on it there. [18:25] I've been using it lately and its working out nice [18:26] justizin: the pmproj file is a work in progress (tm) to include bzr-svn, just remove both bzr-svn entries and it 'll build ok :p [18:26] so my project might include these folders: trunk/ add-openid/ jquery126/ [18:26] ok [18:26] all branches [18:26] i was thinking about that challenge myself. [18:27] are you just including a copy of svn 1.5 or wha? [18:27] justizin: most of the work is there, just need the glue :) [18:27] justizin: I acctually build bzr-svn against both versions of subversion (1.4 and 1.5) [18:28] justizin: and adds a check like the python-2.5 one [18:28] interesting.. [18:28] 1.4 needs to be patched to work, though, eh? [18:28] justizin: not any more, bzr-svn now provides it own bindings [18:28] ah-ho [18:28] neato [18:29] oh, Verterok, you're Guillermo! Nice to meet you and nice work on the project. [18:29] i've just been using bzr-svn on my ubuntu box, then grab a copy using straight bzr from mac or other servers like RH which don't have bzr-svn yet [18:29] still will keep doing that but it'd be nice to have bzr-svn around other places sometimes :) [18:29] newz2000: thanks! it's greatly appreciated! :D [18:30] newz2000: maybe your need can be solved if bzr-eclipse provides a way to branch directly from a project [18:30] I wonder if it would be better to file a bug/feature request on eclipse, though I'm not sure how responsive they are [18:30] so that vcs can just live in sub folders [18:30]