[00:10] hi all, I've got files in d:\project\subdir under version control and I'd like to add files in d:\project. I'd say I need to change the root bzr directory to d:\project - how do I do that & preserve the history in subdir? [00:12] I guess I could just move the .bzr directory and then "bzr move --after" all the original files into subdir? [00:12] thoughts? [00:15] You could probably do this with rich roots. [00:17] what are rich roots? [00:19] The / directory entry of the branch is versioned. I'm pretty sure it's possible to move it. [00:22] Peng: so I could convert the repo to rich roots format and then move the root somehow? [00:23] dhon_: Maybe. [00:24] I dunno. [00:24] I just tried it and it tracebacked. [00:30] Peng: what commands did you use? [00:31] dhon_: "bzr mv . foo". Traceback. :) [00:32] I'm pretty sure rich root formats should be able to support that; perhaps bzr doesn't yet though. [00:39] Peng: I doubt that will ever work - it doesn't even work for a regular mv [00:39] Ok. [00:39] Shucks. [00:40] Peng: Although the error message should obviously be more sensible [00:40] Peng: what exactly are you trying to do? [00:41] I was seeing if it was possible to move the root. [00:42] Peng: it is certainly possible to change the root - see the split command [00:50] jelmer: I was trying to move the root from d:\project\subdir to d:\project [00:50] so I could add files at that level [00:51] I want the files in subdir to stay there (and to keep their history) [00:54] on another note: is it possible to "branch" or "copy" a single file in a repo into two separate files? [00:54] eg 1.txt to 1a.txt & 1b.txt? [01:07] dhon_: "bzr join" should be able to do that [01:08] dhon_: (moving the root from d:\project\subdir to d:\project) [01:08] dhon_: There's no way to split a file at the moment [01:38] jelmer: thanks - help shows join as still experimental as of 1.2 so I think I'll stay clear for the moment === jamesh__ is now known as jamesh === mark1 is now known as markh [07:24] jelmer: Is it just me, or did you define CachingParentsProvider twice? [08:22] jelmer: Congrats on the release! === RAOF_ is now known as RAOF [09:56] hello [09:56] does bzr uncommit actually revert your files [09:57] no [09:57] I'm trying to change the revision log and bzr uncommit seems to be the only way to do so [09:57] (the point of uncommit is to not revert the files) [09:57] bob2: what does the --dry-run flag do? === aantn is now known as aantn|pancakes [10:03] just show you what it would do (which is not all that useful for 'uncommit') === aantn|pancakes is now known as aantn === doko_ is now known as doko === mw|out is now known as mw [13:36] Hi, I'm seeing "authorization failed" trying to push to an svn repository. svn has already cached my credentials. What am I missing? [13:37] fbond: have you prefixed the URL with svn+ ? [13:37] Oh, hmm... [13:37] Yes. [13:37] Pushing to svn+http://... [13:37] what os are you on? The caching trick doesn't work on Windows or Mac OS X [13:37] Oh, maybe... [13:37] I'm on LInux [13:38] But I'm pushing to the trunk URL, should I instead be pushing to the repository root? [13:38] no, you should indeed be pushing to the trunk URL [13:38] Oh, okay. [13:38] committing to this repository using SVN works ok, without any passwords being prompted? [13:38] Yep, that's right. [13:38] bzr: ERROR: Permission denied: ".": CHECKOUT of '/logistix/!svn/ver/183/trunk/pkg-src': authorization failed (http://svn.local.network) [13:39] The error is on CHECKOUT, which is interesting... [13:41] I'm using bzr-svn 0.4.8, bzr 1.2 [13:42] jelmer: I'm using a bzr branch, not an svn wc. That's normal, right? [13:42] jelmer: i.e. I made the branch with `bzr branch ...'; is this even relevant? [13:43] fbond: yeah, that all sounds fine [13:44] fbond: what version of svn are you using? [13:44] On my workstation: version 1.4.4 (r25188) [13:45] On the server: version 1.3.2 (r19776) [13:45] jelmer: Do you need mod_svn version info? [13:45] Odd_Bloke: thanks :-) [13:46] Peng: Whoops, fixing.. [13:48] fbond: Sorry, no idea [13:49] fbond: and you were able to create a bzr branch of the svn branch earlier without problems, or does that not require authorization? [13:55] jelmer: only write access requires auth. [13:56] jelmer: I'll try making the branch again, I think I made it with an earlier version of bzr/bzr-svn... [13:56] fbond: that shouldn't be relevant [13:56] jelmer: Hmm. Is there any way to turn on debug logging so I can see what's going on? [13:57] fbond: running bzr with -Dtransport will print to ~/.bzr.log what it is trying to do [13:59] jelmer: thanks! [13:59] fbond: there is no way to debug the authentication step though - that all happens deep down inside the subversion libraries [14:05] andrea-bs: bzr builddeb does not use LP as it's bugtracker, do you have a link to the upstream one? [14:07] rexbron: the exception was raised by bzr itself, so you should file a bug against bzr [14:07] andrea-bs: kk [14:07] andrea-bs: afiak it just uses the debian bugtracker [14:08] jelmer: thanks [14:14] andrea-bs: https://bugs.edge.launchpad.net/bzr/+bug/206013 [14:14] Launchpad bug 206013 in bzr "bzrlib.errors.ObjectNotLocked: KnitPackRepository('...') is not locked error when using --merge mode" [Undecided,New] [14:14] thanks rexbron [14:15] I would still like to file a bug against bzr-builddeb for the uncommited changes problem [14:15] does anyone have a link to their tracker? [14:16] rexbron: bugs.launchpad.net/bzr-builddeb [14:16] james_w: I was intending to file it against the upstream code base [14:17] rexbron: I'll move the existing bug over, thanks. [14:17] ok will post a link soon [14:19] rexbron: ah, I never enabled launchpad bugs for it, I'll move it to the Ubuntu package for now. [14:20] rexbron: please don't use pastebin for tracebacks on bug reports, as they expire. [14:20] I will not in future, I just looked at the scroll back from an earlier conversation [14:22] rexbron: mh... strange... I'm not able to reproduce the situation [14:23] andrea-bs: Could be a pecurilarity of the branch [14:23] rexbron: could you give me the exact command you used, please? === kiko-afk is now known as kiko [14:24] andrea-bs: just to remind you, this is from a script not from the commandline [14:24] rexbron: oh, right [14:24] I am making this call: [14:24] builddeb.run(branch=self.debianLocalLocation, result='./build-area', orig_dir='./', builder='dpkg-buildpackage ' + self.debuildOptions, merge = True) [14:24] jelmer: got my issue resolved; svn was acting *very* oddly... [14:25] jelmer: it seems that it cached auth info that worked for me, but wasn't my user, or something similar. [14:25] I minimized the server-side config to allow just me, and it asked for a new password. [14:25] Dunno [14:25] Fixed now, anyway. [14:27] https://bugs.edge.launchpad.net/ubuntu/+source/bzr-builddeb/+bug/206021 [14:27] Launchpad bug 206021 in bzr-builddeb "builddeb should raise a python exception when the .run() method is called and there are uncommited changes to the working tree" [Undecided,New] [14:29] andrea-bs: as for the first bug I reported, it could have something to do with the watch file not existing [14:30] rexbron: does "debian.bleedingedge/.bzr" exist? [14:30] New bug: #206013 in bzr-builddeb "bzrlib.errors.ObjectNotLocked: KnitPackRepository('...') is not locked error when using --merge mode" [Undecided,New] https://launchpad.net/bugs/206013 [14:31] andrea-bs: yes, otherwise bd would not work if the orig-dir is set correctly [14:32] jelmer: I probably would have seen the issue right away in ~/.subversion/auth/svn.simple; everything is in plain text in a file whose name looks like a hash. [14:32] jelmer: may want to suggest that if anyone else asks. [14:33] jelmer: also, this is an interesting passage from the svn book: [14:33] http://svnbook.red-bean.com/en/1.4/svn.serverconfig.pathbasedauthz.html; Partial Readability and Checkouts [14:33] jelmer: thanks again [14:40] rexbron: sorry, I can't reproduce it: I get every time a IOError (No such file or directory) :( [14:42] andrea-bs: try and pull this branch https://code.edge.launchpad.net/~ubuntu-bleedingedge/blender/debian.bleedingedge [14:43] rexbron: done [14:43] still the same error? [14:43] rexbron: there's no "blender-svn.py" file [14:44] andrea-bs: copy the bzr-bd.run() method I posted (replacing the varriable where nessicary) and try it out [14:47] rexbron: Could not find the upstream tarball after uscan [14:47] it won't as I am creating it at run time [14:52] rexbron: I've tried with all possible orig-dirs, they all raise a good exception to me [14:53] andrea-bs: Could it be version specific? [14:53] rexbron: probably, which version of bzr and builddeb are you using? [14:54] I am running bzr 1.0 and bd 0.90 [14:54] Ubuntu Gutsy with backports [14:54] oh, now I understand [14:54] :) [14:54] I'm using bzr 1.2.0.candidate.1 and builddeb 0.92.0dev0 [14:55] * rexbron appolgises not not mentioning this sooner [14:55] you told me you were using the 1.0 so I was thinking you were on hardy [14:55] I mark the bug as "Fix released" so [14:55] andrea-bs: wait [14:55] I will try to reproduce it on hardy and if not, we can mark it as released [14:55] rexbron: sure [14:56] rexbron: ok, great idea [14:58] rexbron: generally I prefer to close bugs and reopen them because sometimes the reporters forget to tell if the bug still occur, so I'm going to mark it "Incomplete": it will expire after 60 days [14:58] ok [15:09] rexbron: the raising an exception thing is completely different in newer releases. [15:09] rexbron: it doesn't complain at all and just builds the working tree. [15:12] james_w: ok [16:08] hello people.. [16:08] I have a doubt with bzr-svn .. [16:09] hi c0le [16:10] james_w: I noticed that bzr-svn is adding an entry to the bzr:revision-id:v3-trunk property of svn every time I do a commit.. [16:10] Does this list of entries in the property keep increasing ? [16:11] or does it get recycled after reaching a max number of entrieS? [16:12] I don't know, I think it keeps increasing. [16:12] james_w: Ouch :-S that would look bad after a 1000 such commits.. [16:12] I think that entry contains the full revision history [16:13] so yes, it'll increase afaik [16:13] c0le: are you using trac? [16:13] james_w: Yes, and I can see the list increasing over each commit.. [16:14] james_w: i.e., trac shows it in the changeset.. [16:14] c0le: I think there's a way to turn of the display of them. [16:15] james_w: Aw.. something like 'ignore property'? [16:16] c0le: I've no idea what the option is, I just think I remember someone mentioning such a thing before. [16:16] Hmm.. I wonder how git-svn does this tracking.. [16:16] james_w: ok.. i'll google on that.. [16:16] it doesn't [16:17] james_w: ah, ok.. === kiko is now known as kiko-fud [17:08] * lamont tries again to understand how to break from bzr's belief that he wants a directory-per-branch and create a single working tree with multiple branches in it that he can switch between [17:10] lamont: bzr init-repo --no-trees foo; bzr init foo/branchA; bzr co --lighweight foo/branchA workingtree [17:10] then you can have as many treeless branches under foo as you want [17:10] and switch the working tree with bzr switch [17:11] c0le: git-svn doesn't do tracking as far as I know [17:11] c0le: bzr-svn 0.5 will hopefully support storing that sort of metadata in revision properties rather than file properties [17:13] * lamont wonders "what sort of tracking"? [17:15] lamont: All bzr-specific metadata [17:15] ah, ok [17:15] lamont: so it is possible to push a bzr branch into svn and then create that exact same branch again from the data pushed into svn [17:20] jelmer: isn't it that git doesn't need to, as its model doesn't create a parallel imports problem? [17:20] lamont: cbranch from bzrtools may also help with that workflow. [17:20] james_w: it still stores more metadata than svn can [17:21] like full author name [17:21] author name, author date, etc. [17:21] or timezone [17:21] james_w: it reduces the need for full round-tripping support [17:22] ah, ok. [17:57] hi, i'm trying to install Bazaar on windows following the quick install guide (the python one), but i get stumped here . . . [17:58] "Bzr Tools and Bazaar GUI needs to be compiled. Use same procedure as for compiling Paramiko." i fail at finding how to compile Paramiko :P [17:58] any advice ? :) [17:58] python setup.py install? [17:59] lol, that simple ? thanks :D [17:59] I don't really know, just guessing [18:00] well, looks like that did it. thanks again :) === kiko-fud is now known as kiko [18:52] hi, I've got another bzrlib question: what is the easiest way of getting the 'kind' of an unknown file in a workingtree? [18:53] thekorn: osutils.file_kind is what you want I think [18:53] jelmer, another question for you - should this be reported as a bug?: "Using saved location: https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk [18:53] bzr-svn is not up to date with installed bzr version 1.3. [18:53] There should be a newer version of bzr-svn available. [18:53] bzr: ERROR: Transport operation not possible: http does not support mkdir() [18:53] " [18:54] arnetheduck: are you doing push? [18:54] jelmer, when pushing a new directory to svn... [18:54] james_w, yes [18:54] can you try "bzr push svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk" [18:57] james_w, I think it may be working since the command is taking a lot longer now =) [18:58] (it's a big commit and sf isn't the fastest site on the net [18:58] arnetheduck: if it works do "bzr push --remember svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk" [18:58] james_w, oh, i'm too much focused on bzrlib that I don't see the obvious [18:59] thekorn: no problem [18:59] james_w, that's what I did actually =) [19:00] arnetheduck: great, your faster than me :-) [19:01] james_w: I would use Tree.kind, unless trying to get the kind of unversioned files. [19:02] arnetheduck: to push new branches, use "bzr svn-push" [19:02] jelmer, it wasn't a new branch, just a new dir in an existing branch... [19:03] thekorn: you said "unknown" you meant "unversioned" rather than "arbitrary" didn't you? [19:03] jelmer, btw, should I worry about the 1.3 warning? [19:03] arnetheduck: how do you mean? [19:03] "bzr-svn is not up to date with installed bzr version 1.3" [19:04] arnetheduck: 0.4.9 is out and supports bzr 1.3 [19:05] thekorn, well, I think i'm a bit confused: I would like to get all files which are in the 'unknown' section when I run 'bzr status' [19:05] james_w, i meant [19:05] jelmer, bugger, I checked yesterday I think and it wasn't =) [19:05] arnetheduck: the warning itself isn't really worrysome but you'll find that one or two things give tracebacks [19:05] james_w, and I thought I could get these files with tree.unknowns() [19:06] but this does not work as expected [19:07] thekorn: yes, I think that's right, and in that case osutils.file_kind is the correct function to use to get the kind. [19:07] what do you get that you don't expect? [19:10] james_w, damn I'm always mixing workingtree and revisiontree, sorry, my problem is that list(revtree.unknowns()) always returns an empty list [19:10] when revtree is an revisiontree object [19:10] jelmer, the one I reported the other day? something about some revision number being wrong? [19:11] thekorn: I think that's right isn't it? [19:13] james_w, I don't know, have not read any documentations on this, can't revision trees have unknown files? [19:14] and if so, why is there a unknowns()-method for RevisionTree-objects? [19:15] Hmm, one project moved its svn repo to Google Code. Does svn consider the repos different and does bzr-svn? [19:17] Hmmm, I think it might have changed significantly. [19:17] There are fewer revisions in G Code. === mw is now known as mw|food [19:19] thekorn: a revisiontree is a committed state, so I think it makes sense for it to have 0 unknowns [19:19] as to whether the method should be implemented on it I am not too sure. [19:20] james_w, yes this makes sense, thank you [19:21] james_w, here's what I got now: bzr: ERROR: libsvn._core.SubversionException: ("MKCOL of '/svnroot/dcplusplus/!svn/wrk/0dd13b40-b1d2-4fab-9b0e-5fb8b3a13bb3/dcplusplus/trunk': 405 Method Not Allowed (https://dcplusplus.svn.sourceforge.net)", 175002) [19:23] arnetheduck: I have no idea about that I'm afraid. [19:25] It's implemented on Tree so that we don't have to special-case other functions depending on their Tree type. [19:34] jelmer, how about http://www.pastebin.ca/955617? [20:08] arnetheduck: one sec === mw|food is now known as mw [20:09] arnetheduck: doesn't make much sense to me. I don't understand why bzr would be trying to create a directory there [20:18] jelmer, it does make sense - svn by default first creates a working folder for the transaction, commits everything there and then moves the transaction to a new revision file... [20:19] jelmer, could it be that the digest auth is not being sent (when using pure svn, my credentials are fetched automagically)? [20:25] arnetheduck: that all happens under the hood though - the protocol doesn't include commands like that [20:27] arnetheduck: does "bzr branch " list the branch you're trying to push to? [20:46] New bug: #127734 in bzr-gtk "Progress bars as widgets" [Medium,Triaged] https://launchpad.net/bugs/127734 === barry is now known as barry-away [20:57] moin [20:58] lifeless: moin [20:58] hey lifeless, abentley [21:04] jelmer, I've successfully committed to the svn branch before, but never with a new directory [21:05] arnetheduck: you added a new directory in your bzr branch and you're now trying to push the revision that added that directory? [21:14] jelmer, correct [21:14] jelmer, now that I think about it, I first removed a directory and then added one with the same name [21:15] jelmer, hm, that makes it two revisions to commit - one that removes a directory (and contents), then another that adds a directory (and contents) with the same name as the one removed [21:16] arnetheduck: that shouldn't be relevant here though [21:16] the mkdir call you're seeing is about creating a new branch, not about a directory in a branch [21:17] jelmer, I'll try again, maybe it was some temporary error [21:18] arnetheduck: I doubt that [21:18] arnetheduck: does "bzr branch " list the branch you're trying to push to? [21:18] arnetheduck: sorry, I mean "bzr branches " [21:23] jelmer, running... [21:31] * Peng wonders what bzr-svn is doing. [21:32] Augh! [21:33] It took like 2 minutes to pull 1 revision! [21:33] Peng: are you using 0.4.9 ? [21:34] jelmer: I'm using yesterday's 0.4 branch. [21:34] Peng: the development branch can have major performance regressions while in flux [21:34] Apparently so. [21:37] hiya [21:37] Hello. [21:38] what would be the easiest / best way of serving a writeable public repo with authentication? [21:39] mathrick: bzr+ssh? [21:40] Peng: and without ssh? [21:40] webdav? [21:40] okay, I guess ssh is the easier way then [21:41] Yeah. [21:41] If it's a FOSS project, you could use Launchpad. [21:41] it's not, not yet anyway [21:45] jelmer, it's still stuck... [21:46] arnetheduck: in the "bzr branches.." run? [21:46] it took only a minute or so here.. [21:46] jelmer, here's what I tried: "bzr branches svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk" [21:47] arnetheduck: please try the repository url [21:47] bzr branches [21:47] svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/ [21:57] Good morning. [21:59] hi [22:24] bzrserve@sei.meidokon.net's password: [22:24] Server is too old for fast get_parent_map, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this) [22:24] bzrserve@sei.meidokon.net's password: [22:24] why does it have to reconnect? [22:25] it makes me input the password twice [22:25] mathrick: because the server is too old. [22:26] yeah, but why does it have to reconnect to use the older protocol? [22:28] mathrick: because the older protocol wasn't designed to allow graceful degradation in the case where a client sends a request with a body but the server doesn't recognise the request [22:28] mathrick: because the old protocol let the server get confused about edge of messages [22:29] aha, not nice of it [22:29] mathrick: so there was no way to be sure when it was actually ready for new input [22:38] jelmer, bzr branches svn+https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/ returned nothing [22:41] arnetheduck: what do you have the branching scheme set to? [22:45] auto I think, didn't specify anything, and when importing it got my branches right so... [22:45] jelmer, sorry, gotta go, I'll check back tomorrow... [22:45] the fact "bzr branches" returns nothing suggests something may be wrong there [22:45] arnetheduck: what does "bzr svn-branching-scheme " print? [22:46] New bug: #206242 in bzr-svn "Add append-revisions-only setting for Subversion repositories" [Wishlist,Triaged] https://launchpad.net/bugs/206242 [22:58] spiv: looks like only us around; point 2 point call ? [22:59] lifeless: sure. [23:04] morning [23:22] is it possible to branch or export a subdirectory of a repository? maybe this is called NestedTreeSupport ? [23:23] evarlast: To turn a subdirectory of a branch into its own branch, see bzr split. [23:24] evarlast: we discussed this in london [23:24] you can also split as Peng says [23:24] igc: hi, spiv and I just did a p2p call as we couldn't see any others :> [23:26] hi lifeless [23:26] igc: FWIW, my plan for the day is email + smart impl of set_last_revision_info [23:27] spiv: thanks [23:27] thank you so much. I searched as searched and could not find split. [23:28] spiv,lifeless: my plan for the day is ... email + reviews + package the new hook we worked on at PyCon [23:33] igc: I'm working on versionedfiles [23:37] New bug: #206258 in bzr "incompatible repository error messages are unhelpful" [Undecided,New] https://launchpad.net/bugs/206258 [23:53] hi folks [23:53] are 1.3 packages available in the usual ppa? i haven't seen them for hardy yet [23:54] and is there an agreement with the distro team to put 1.3 into hardy itself (not the ppa)? [23:56] sabdfl: The PPA takes a few days to update. [23:56] Hey, hg 1.0 is out. :) [23:57] thanks peng, and congrats on the 1.0 === mw is now known as mw|out [23:58] Not congrats to me. [23:58] I mean, I'm not one of their developers. [23:58] ah, thought you were [23:58] I'd *like* to be, if I was smart enough. :P [23:59] (I'd like to do more than typo fixes on bzr too. I'm not a traitor!)