| jelmer | yacc: package support? | 00:00 |
|---|---|---|
| yacc | Well, if you want to make bzrlib.plugins.svn.lowlevel a module, you need to store that path in the filename of the .pyx for Pyrex. Cython automatically detects the package path. | 00:00 |
| jelmer | ah | 00:01 |
| yacc | In theory it works with Pyrex too, and you might get by my making the module thing it's something else that it is (as long as you do not need introspection about what module you are), ... | 00:01 |
| Peng | Also, isn't Cython supposed to have more optimizations? | 00:01 |
| yacc | Peng: it is. | 00:01 |
| Peng | Yeah, but I mean is more more than 3% faster? | 00:02 |
| Peng | Bzr is kind of laughably slow on Python's branches... | 00:02 |
| yacc | Peng: that depends on your code. For a C-library binding to Python it should make no real difference. | 00:02 |
| yacc | Peng: that's kind of because Python is a huge svn repo. Importing python into an svk depot is beyond laughable, it's more like crying from pain. | 00:03 |
| jelmer | yacc: ah, ok. I have no use for that right now though, so I'll try to keep the .pyx file usable by both as long as I can | 00:03 |
| Peng | yacc: Heh. Like I said, "missing" took a couple minutes, and "diff -c" is quite slow too. | 00:03 |
| jelmer | the C file generated by pyrex is 6500 lines, the one from cython is almost 11000 lines | 00:04 |
| yacc | missing? | 00:04 |
| yacc | jelmer: why do you care? | 00:04 |
| Peng | Woah. | 00:04 |
| Peng | yacc: "bzr missing". | 00:04 |
| yacc | jelmer: I mean how big is the difference in compiled size? | 00:04 |
| jelmer | yacc: It makes reading the source harder | 00:04 |
| yacc | jelmer: C is whitespacy language. | 00:04 |
| Peng | I was gonna say "who cares" assuming it was a small difference, but that is kinda significant. | 00:05 |
| yacc | jelmer: you don't want to read the source. Not as long as you don't want to debug or help debug Cython/Pyrex. | 00:05 |
| yacc | jelmer: kind of like me ended up peeking at your code :-P | 00:05 |
| jelmer | yacc: you end up having to | 00:06 |
| jelmer | yacc: pyrex catches a lot more errors in the .pyx file than swig does in its .i files | 00:06 |
| jelmer | but it still occasionally generates .c files that dont compile because of incorrect .pyx files | 00:06 |
| jelmer | and then you actually have to check the c file to see what is going wrong | 00:07 |
| yacc | jelmer: I was lucky with Pyrex (back then there was no Cython) that I did not need to debug the generated code :) | 00:07 |
| jelmer | or in the case of segfaults | 00:07 |
| yacc | jelmer: In my case back then in '03/'04, swig and the C++ core app where the usual culprits for "problems" ;) | 00:08 |
| jelmer | :-) | 00:08 |
| jelmer | if you guys have experience with pyrex, you may actually have a clue how to work around the issue I'm facing at the moment | 00:09 |
| yacc | jelmer: and well, nobody cared about all my little problems. The bad guys (as curious that sounds that was the sister company in NL) kept us busy with trying to decipher the file format ;) | 00:10 |
| jelmer | I've got a callback function in pyrex that needs to return a pointer to an error whenever an exception occurs | 00:10 |
| yacc | jelmer: tell, perhaps I can help. | 00:10 |
| yacc | paste? | 00:10 |
| yacc | Or branch url? | 00:10 |
| yacc | error being what data type? | 00:11 |
| jelmer | http://paste.ubuntu-nl.org/60476/ | 00:11 |
| jelmer | the error is a pointer to a structure | 00:11 |
| jelmer | or NULL in the case no error occurrs | 00:11 |
| yacc | And what is your problem then? | 00:12 |
| jelmer | if an exception occurs in self.set_target_revision(target_revision) I need to return a pointer to an error rather than NULL | 00:13 |
| yacc | try: except: | 00:13 |
| jelmer | I haven't figured out a way to do that yet though | 00:13 |
| yacc | put a try: except: as in Python around the call. | 00:13 |
| jelmer | yacc: I need to retain the exception as well | 00:13 |
| yacc | Well, in any chance to piggy pack it onto svn_error_t? | 00:14 |
| yacc | If not, you will probably need to keep it in a dictionary keyed by pointer address? | 00:14 |
| jelmer | ieuw | 00:17 |
| jelmer | yeah, I guess that would work | 00:18 |
| yacc | nobody said that it's cool to wrap a C API, especially one that uses callbacks and other stuff for a language like Python. | 00:19 |
| yacc | One of the better things about the Gnome Project was that it realized that from the beginning, and despite some flames, they managed to make their APIs "wrapping-friendly" ;) | 00:20 |
| jelmer | the svn API is pretty good overall | 00:25 |
| jelmer | pyrex is a little less powerful than swig though (which is used for python-subversion) | 00:25 |
| jelmer | the language is a lot saner though | 00:25 |
| * Peng gets a traceback using bzr-svn on Lighttpd's repo. | 00:28 | |
| Peng | Somebody forgot to import "errors" in svk.py. | 00:29 |
| Peng | Well, I guess it'd just error out anyway for a different reason if it weren't for that. :P | 00:29 |
| yacc | less powerful? | 00:38 |
| yacc | I wouldn't say so. It's just way less automatic. OTOH, when you wrap something, you get usually a better designed wrapping, and potentially a faster one. | 00:39 |
| * Peng notices that his copy of bzr-svn is out-of-date. | 00:40 | |
| radix | Peng: oh yeah, I've been noticing that like 100 times a day lately | 00:44 |
| Peng | Ok, updating didn't help. | 00:45 |
| jelmer | Peng: What branch are you using? | 00:46 |
| Peng | jelmer: Hold on. | 00:46 |
| Peng | jelmer: .bzr.log http://paste.pocoo.org/show/34862/ | 00:48 |
| Peng | jelmer: svn://svn.lighttpd.net/lighttpd/trunk/ | 00:48 |
| Peng | jelmer: svn import on the repo did it too | 00:48 |
| Peng | jelmer: Latest bzr-svn 0.4 and bzr.dev as of five minutes ago. | 00:49 |
| jelmer | Peng: You shouldn't get a out-of-date error with bzr-svn 0.4 though | 00:51 |
| jelmer | Peng: I've fixed the import error | 00:52 |
| Peng | Thanks. | 00:53 |
| Peng | Responsive developers are awesome. | 00:53 |
| Peng | jelmer: Um, yeah, now it works. Thanks. :) | 00:59 |
| jml | jelmer: that reminds me, the 0.4.8 branches works really well with the o-hand.com repos. | 01:07 |
| jelmer | cool :-) | 01:24 |
| ubotu | New bug: #145171 in bzr-svn "Invariant break on bzr missing in bzr-svn" [Medium,Incomplete] https://launchpad.net/bugs/145171 | 01:36 |
| ubotu | New bug: #94316 in bzr-svn "Traceback doing log -v" [Low,Triaged] https://launchpad.net/bugs/94316 | 02:26 |
| awmcclain | Where does bazaar.conf live? In site-packages? | 02:39 |
| abentley | awmcclain: in ~/.bazaar | 02:40 |
| jholman | I want to install bazaar on an ubuntu box. I am pretty much an ubuntu noob, I confess. I followed the link to the bazaar launchpad site, and added the 2 gutsy lines to my sources.list, and did apt-cache show bzr... | 03:15 |
| jholman | and I get 2 entries, first of all (one out of the main ubuntu package repository, I guess?)... and they're both old versions | 03:16 |
| jholman | 1.2-1 and 0.90-1 | 03:16 |
| fullermd | Well, 1.2 is only old as of, like, 12 hours ago or something. | 03:17 |
| jholman | fair enough. | 03:18 |
| jholman | so the reasonable thing to do is to trust apt, remember that I should do an update/upgrade in a day or three, and go from there? | 03:18 |
| fullermd | With the caveat that I don't really know anything about Ubuntu packaging (or package using), that sounds right. | 03:18 |
| jholman | hmn, significant caveat, but fair enough | 03:19 |
| * fullermd is all about ambiguity, except when he's not :) | 03:20 | |
| jholman | =] | 03:20 |
| abentley | "We demand rigidly defined areas of doubt and uncertainty!" | 03:30 |
| * fullermd demands that he may or may not know about a bzr release. | 03:30 | |
| abentley | Well, we haven't been quite punctual about getting the debs out in the past. | 03:32 |
| abentley | Yes, it does look like 1.3 hasn't hit our repo yet. It should in the next few days. | 03:33 |
| jholman | ok | 03:34 |
| Odd_Bloke | Morning. | 03:50 |
| rusty | Hi all: I'm struggling to find out if there is an answer to the question of setting up multiple committers to a (remote) repository. | 04:06 |
| jml | rusty: hi. | 04:07 |
| jml | rusty: you mean multiple people pushing to the same branch? | 04:07 |
| rusty | jml: yes. | 04:07 |
| jml | rusty: that should pretty much work out of the box. what problems are you having? | 04:08 |
| rusty | jml: well, currently I'm using rsync to send to server, but that won't work for the second committer. | 04:09 |
| rusty | jml: so I wondered what the "correct" way to do this is. | 04:09 |
| jml | rusty: well, the "correct" thing is both people should be using 'bzr push bzr+ssh://..." | 04:10 |
| jml | but let me do an experiment | 04:10 |
| rusty | jml: for mercurial, I have an acct on the server with write access to the repo and put their ssh key in the authorized_keys with command= | 04:10 |
| jml | rusty: is the issue is that the push overwrites permissions / ownership? | 04:11 |
| jml | you could do that with bzr, I think | 04:11 |
| rusty | jml: no, sorry, the issue is that I haven't tried it, was looking for advice :) | 04:12 |
| jml | oh :) | 04:12 |
| jml | so, I think you don't have to do that, if you wanted you could have an account per user. | 04:12 |
| jml | (that's what I'd do, if I weren't using something like PQM) | 04:12 |
| rusty | jml: I really don't want to hand out accounts on the server. | 04:12 |
| jml | rusty: you could also do what you just described -- a special account with authorized_keys | 04:13 |
| jml | rusty: alternatively, you could use Launchpad (but I'm guessing you want to host this yourself). | 04:13 |
| jml | rusty: what do you know about PQM? | 04:15 |
| rusty | jml: nothing, I just googled it when you mentioned it :_ | 04:15 |
| jml | rusty: ok. PQM acts like an automated gatekeeper. You send it signed emails and it does the merge. | 04:16 |
| jml | rusty: Bazaar itself uses PQM to make sure that the test suite passes before it lands anything. | 04:16 |
| jml | rusty: I haven't set it up myself, but if that sort of thing appeals to you then you might want to check it out. | 04:17 |
| jml | (is this for libantithread, perchance?) | 04:17 |
| rusty | jml: ccan :) | 04:17 |
| jml | heh. | 04:18 |
| rusty | jml: OK, I think I'll try adapting the "hg-ssh" wrapper for bzr. Looks like it'll be fairly easy. | 04:20 |
| * jml thinks | 04:20 | |
| jml | rusty: why do you need a wrapper? | 04:21 |
| rusty | jml: you use "command=wrapper <repos>" and it restricts that key to only running bzr, and what repositories it can access. | 04:21 |
| rusty | jml: it's a cute ssh feature (the command they wanted to run is in $ORIG_SSH_COMMAND) | 04:22 |
| Odd_Bloke | jml: http://bazaar.launchpad.net/~daniel-thewatkins/+junk/merged-branches now has working shelved changes logic, and a test to go with it. | 04:24 |
| jml | Odd_Bloke: you mean my previous logic was not working? inconceivable! | 04:24 |
| jml | rusty: it'd be cool if you could post it to the Bazaar ML once your done. That is, if there's anything interesting and not site-specific :) | 04:25 |
| rusty | jml: sure! | 04:26 |
| Odd_Bloke | jml: It wasn't so much that the logic wasn't working as that you weren't actually referencing bzrtools and you were getting hit by double-underscore munging. :p | 04:27 |
| jml | Odd_Bloke: I guess now that I've got more than one user and more than one contributor I should register a project for it. | 04:27 |
| jml | Odd_Bloke: can you suggest a name better than "merged-branches"? | 04:28 |
| Odd_Bloke | jml: The little thought I've given it didn't produce anything better, sadly. | 04:28 |
| jml | Odd_Bloke: merged-unchanged-unshelved-branches doesn't have quite the same _energy_. | 04:29 |
| jml | Odd_Bloke: what do you think of 'boring-branches'? | 04:29 |
| Odd_Bloke | jml: I'm not sure it conveys enough of what it actually means. How about 'redundant-branches'? Or 'removable-branches'? | 04:32 |
| Odd_Bloke | Perhaps 'excess-branches'? | 04:32 |
| jml | luxury-branches :) | 04:32 |
| fullermd | this-is-an-ex-branch | 04:33 |
| Odd_Bloke | gratuitous-branches :p | 04:33 |
| jml | ok. As benevolent dictator for today, I am going to call the project bzr-removable | 04:34 |
| jml | Odd_Bloke: OK w/ MIT license? | 04:36 |
| Odd_Bloke | jml: I'd prefer GPL, but I'm easy. | 04:37 |
| jml | fine by me. | 04:38 |
| rusty | jml: Erk, hit a snag. bzr push bzr+ssh runs 'bzr serve --inet --directory=/ --allow-writes' on the remote end, indep. of what repo it's trying to access. | 04:39 |
| rusty | jml: Makes it hard to restrict the repo by looking at command line. | 04:39 |
| rusty | jml: (0.9 does this as well as 1.3) | 04:40 |
| jml | *nod* | 04:40 |
| jml | I should have foreseen that, sorry. | 04:40 |
| * jml has a look around | 04:40 | |
| jml | rusty: ok, so I have a crummy workaround. | 04:42 |
| jml | rusty: but it's pretty terrible. | 04:42 |
| rusty | jml: well, I was going to ignore it for the moment, so I doubt yours will be worse :) | 04:42 |
| jml | (Bazaar should change to let you specify a directory) | 04:43 |
| jml | rusty: you were warned | 04:43 |
| jml | rusty: you can tell it which bzr executable to run using BZR_REMOTE_PATH. | 04:43 |
| jml | and then you could dispatch off that. | 04:44 |
| rusty | Erk, I was thinking to change --directory=/ to --directory=<acct home dir> so they can only access stuff in their home? | 04:45 |
| jml | rusty: yeah, that would be better if you could do that :) | 04:45 |
| jml | rusty: but if you have a wrapper script that's parsing the contents of SSH_ORIGINAL_COMMAND then you could do something horrible based on the specified location of the bzr executable. | 04:46 |
| jml | ugh. | 04:46 |
| jml | that's a bad idea, forget I said anything. | 04:47 |
| jml | Odd_Bloke: with bzr plugins, is there a convention for the team that owns trunk? | 04:49 |
| rusty | jml: hmm, want to give me a hint on how to s,--directory=/,--directory=sys.argv[1], in python? And then exec it? | 04:49 |
| jml | rusty: sure | 04:50 |
| jml | os.system(command_string.replace('/', sys.argv[1], count=1)) should do the trick. | 04:51 |
| * AfC waves to rusty | 04:51 | |
| rusty | jml: don't I want .exec to avoid quoting troubles? | 04:52 |
| AfC | rusty: I've been through a lot of the hosting pain; if you're still stuck next week I can totally try to help you out when I get back. | 04:52 |
| rusty | AfC: this is self-inflicted... bzr is the one distributed vc system I hadn't tried yet. | 04:53 |
| jml | rusty: was being quick and dirty | 04:53 |
| AfC | rusty: I've had some nice results, though... things like http://research.operationaldynamics.com/bzr/java-gnome/mainline/ instead of an empty directory | 04:53 |
| * jml always has to look this stuff up | 04:53 | |
| rusty | jml: I think I'm almost there... | 04:54 |
| * AfC really needs to move that server from Europe to western North America somewhere :) | 04:54 | |
| jml | rusty: using exec would work fine too. | 04:54 |
| jml | Odd_Bloke: I'm getting hungry and kind of bored of sitting at a computer. I'll have a play with your branch tomorrow. | 05:02 |
| jml | Odd_Bloke: the bzrtools fix is obviously right :) | 05:02 |
| fullermd | Erk. You wanna be careful playing with that --directory... | 05:02 |
| fullermd | You get too smart, you'll wind up giving yourself big headaches down the road. | 05:02 |
| rusty | jml: woot: $ bzr push bzr+ssh://ccan@ozlabs.org/ccanThis transport does not update the working tree of: bzr+ssh://ccan@ozlabs.org/ccan/. See 'bzr help working-trees' for more information.- [== ] Transferring 0/4 | 05:05 |
| rusty | jml: I ended up with babytalk python: if orig_cmd == 'bzr serve --inet --directory=/ --allow-writes': os.execlp('bzr', 'bzr', 'serve', '--inet', '--directory=' + sys.argv[1], '--allow-writes') | 05:08 |
| jml | rusty: nothing wrong with simple. | 05:08 |
| rusty | jml: no doubt it will break if bzr changes cmdline, but it should be obvious. | 05:09 |
| jml | right. | 05:10 |
| jml | rusty: I look forward to reading your email. :) | 05:11 |
| * jml is really gone now | 05:11 | |
| Odd_Bloke | jml: Sorry, I was playing Peggle. I don't know about convention, enjoy your food and have a good Easter. :) | 05:39 |
| thekorn | hi all, In a script I would like to get all revision numbers of a branch, | 10:10 |
| Odd_Bloke | thekorn: What do you mean by "all revision numbers of a branch"? | 10:10 |
| thekorn | is it save to do something like range(1, number_of_last_rev +1) ? | 10:10 |
| thekorn | Odd_Bloke, a list of all revision numbers of a branch | 10:11 |
| Odd_Bloke | I can't immediately see why not, but that will obviously exclude merged revisions (i.e. dotted revision numbers). | 10:11 |
| thekorn | are this rev numbers continuous and linear? | 10:11 |
| Odd_Bloke | The mainline revision numbers are, but merged revisions use dotted revnos. | 10:12 |
| thekorn | Odd_Bloke, that's fine I'm only intrested in the "main-line" | 10:12 |
| Odd_Bloke | Then you should be fine. :) | 10:12 |
| thekorn | thanks | 10:12 |
| Odd_Bloke | What are you using all the revision numbers for? | 10:13 |
| thekorn | Odd_Bloke, well I started to play around with bzrlib yesterday and I ended in writing a fuse-file-system for bzr | 10:14 |
| Odd_Bloke | thekorn: Ah, interesting. Someone at the sprint was looking at that, though I can't remember who. | 10:16 |
| thekorn | within the filesystem there are two main directorys "revisions" and "tags" | 10:16 |
| Odd_Bloke | thekorn: I think enough people would be interested in looking at that to make it worth sending something about it to the mailing list. | 10:18 |
| thekorn | Odd_Bloke, sure, will push the code to launchpad project soon and can also write a mail to the ML | 10:20 |
| Odd_Bloke | Awesome, thanks. :) | 10:21 |
| nubbun | In bzr 1.3, I have an error loading bzrlib . It recommends setting PYTHONPATH. Setting PYTHONPATH has no effect. | 12:27 |
| nubbun | on this error. The error is still reported. | 12:27 |
| nubbun | Running bzr from the top of its directory tree, works. | 12:27 |
| Odd_Bloke | nubbun: Could you pastebin the error? | 12:33 |
| nubbun | http://www.pastebin.org/24836 | 12:35 |
| Odd_Bloke | nubbun: Just having a look now. :) | 12:45 |
| Odd_Bloke | nubbun: How did you install bzr? | 12:45 |
| Odd_Bloke | And what type of sustem are you on? | 12:45 |
| Odd_Bloke | *system | 12:46 |
| nubbun | extracting a tarbal | 12:46 |
| nubbun | linux | 12:46 |
| nubbun | Debian Etch | 12:46 |
| dato | nubbun: did you cp bzr to your ~/bin? | 12:46 |
| Odd_Bloke | nubbun: So you did 'tar zxvf bzr-1.3.tar.gz' (or equivalent)? Did you take any further steps? | 12:46 |
| nubbun | no did ln | 12:46 |
| dato | nubbun: if so, I recommend that you symlink it instead | 12:46 |
| dato | nubbun: ln -s? | 12:46 |
| dato | or ln alone | 12:47 |
| nubbun | Trying now. | 12:47 |
| nubbun | Now it works as symlink. | 12:48 |
| ubotu | New bug: #205112 in bzr "bzrlib in PYTHONPATH not found" [Undecided,New] https://launchpad.net/bugs/205112 | 13:46 |
| ubotu | New bug: #161830 in bzr-svn "log should show subversion revision numbers as well as branch/bzr revision info" [Wishlist,Triaged] https://launchpad.net/bugs/161830 | 14:14 |
| radix | Am I the only person that often runs into problems using bzr-svn on a project that already uses lots of branch-based SVN development? | 15:10 |
| radix | like, trying to merge stuff with SVN often results in a conflict on "." | 15:10 |
| jelmer | radix: Haven't seen that issue before | 15:11 |
| jelmer | radix: conflict on . ? | 15:12 |
| radix | jelmer: properties, presumably | 15:12 |
| jelmer | radix: Ah, svn merging bzr branches in svn? | 15:12 |
| radix | jelmer: svn merging SVN branches that happened to have bzr commit to them in svn | 15:12 |
| radix | to be precise :) | 15:13 |
| jelmer | That's basically unsupported by bzr-svn at the moment | 15:14 |
| radix | it seems bzr-svn would be great if I were only trying to integrate with projects that mostly do trunk-cowboy hacking | 15:14 |
| jelmer | until the ability in bzr-svn to use revision properties (as opposed to file properties) lands | 15:14 |
| radix | jelmer: ah, that sounds exciting | 15:14 |
| ubotu | New bug: #205156 in bzr "KnitRepository.insert_data_stream() copies data in improper order" [Critical,Triaged] https://launchpad.net/bugs/205156 | 15:26 |
| arnetheduck | hi, I'm about to migrate from svn to bzr and I noticed that there are several options available - does anyone have any tips on which one to choose? | 15:35 |
| arnetheduck | bzr-svn seems nices to me, but it seems like it doesn't keep the tags for example... | 15:35 |
| arnetheduck | (I have a classic trunk/branches/tags type of svn repo) | 15:35 |
| jelmer | arnetheduck: it will keep the tags (if you use "bzr svn-import") but as branches | 15:41 |
| arnetheduck | jelmer, so I noticed - does that make sense? I usually tag my releases (and I don't touch them any more after tagging) so it seemed like real tags were more suitable | 15:55 |
| jelmer | arnetheduck: yes, but there are certain issues that have to be addressed first for that to be supported | 15:59 |
| jelmer | bug 81102 | 16:02 |
| ubotu | Launchpad bug 81102 in bzr-svn "Tag support" [Wishlist,Triaged] https://launchpad.net/bugs/81102 | 16:02 |
| arnetheduck | jelmer, assuming that there were no changes from the tag to it's source revision (which is verifiable via log), it shouldn't be too hard, right? | 16:06 |
| arnetheduck | I poked around in the bzr-svn code a few weeks ago and saw that there are at least some functions for detecting tags / tag dirs | 16:06 |
| jelmer | arnetheduck: tags and branches are considered equally at the moment | 16:08 |
| jelmer | furthermore, you have to make sure the revision that created the tag didn't introduce any other changes to it | 16:08 |
| jelmer | there can be multiple tags directories in a repository, possibly not related to the branch you're checking out | 16:09 |
| ubotu | New bug: #81102 in bzr-svn "Tag support" [Wishlist,Triaged] https://launchpad.net/bugs/81102 | 16:18 |
| dato | arnetheduck: I think you could easily script converting the resulting tag-branches to real tags after bzr-svn did its | 16:29 |
| dato | arnetheduck: job? | 16:29 |
| arnetheduck | dato, that's crossed my mind but would leave some cruft in the repo... | 16:32 |
| dato | arnetheduck: cruft?, what cruft? | 16:32 |
| arnetheduck | dato, the branches | 16:33 |
| dato | arnetheduck: uh, you'd just rm -rf them after converting them to real tags | 16:33 |
| arnetheduck | dato, well, not if they're imported too (they'd show up in logs etc) | 16:34 |
| dato | ok, maybe you're still not fully familiar with bzr and that's why we're not understanding each other :) | 16:35 |
| dato | arnetheduck: each branch is mostly independent from each other, there is no such think as "log for the repository as a whole" | 16:35 |
| dato | does your SVN repo contain many projects, or only one (with its tags, and maybe some branches of it as well) | 16:36 |
| arnetheduck | dato, yep, I'm a 100% noob, as green as they come =) | 16:41 |
| dato | ok. I think the user guide has some parts explaining this stuff, but as a crash course: | 16:43 |
| arnetheduck | dato, it's a single project, no branches, one trunk, tags every now and then | 16:43 |
| dato | - each branch is | 16:43 |
| dato | ok, scratch that | 16:43 |
| arnetheduck | I think get your point though | 16:43 |
| dato | great | 16:43 |
| arnetheduck | I'm kind of used to the svn/cvs mindset after a few years | 16:43 |
| dato | each tag-branch will be like a "cp -r" from the original branch *at some point of its history* | 16:44 |
| dato | so, as svn does "copies", but in its svn-filesystem, you do copies here, but in the real filesystem | 16:44 |
| arnetheduck | dato, yeah, in my mind the branches remained in the .bzr folder thus created cruft, but then it your point sunk in =) | 16:45 |
| dato | ok | 16:45 |
| ubotu | New bug: #205181 in bzr-svn "importing https://svn.xiph.org/trunk/theora fails" [Undecided,New] https://launchpad.net/bugs/205181 | 16:46 |
| arnetheduck | dato, so conceptually, the script would read each branch created by the importer, find out which revision of the trunk branch it was copied from and add a tag to the trunk | 16:56 |
| dato | more or less. if the tag-branches created by bzr-svn contain no additional commits, which I don't think they do but jelmer can confirm, it's just a matter of: | 16:58 |
| dato | for each tag-branch: | 16:58 |
| dato | r=second word of `bzr revision-info` | 16:59 |
| dato | in trunk: bzr tag -r revid:$r $tagname | 16:59 |
| jelmer | they always contain at least one extra revision (the one in which the tag was created) | 16:59 |
| dato | oh, ok | 16:59 |
| dato | then `bzr revision-info -r -2`, with manual supervision, I guess | 17:00 |
| arnetheduck | thanks, brb, gotta feed the kid =) | 17:08 |
| AfC | How many tests in the Bazaar test suite, roughly? | 17:20 |
| * AfC refers to this in our HACKING document as a point in bzr's favour | 17:20 | |
| dato | AfC: the other day 10,000 was reached | 17:20 |
| AfC | dato: nice. 10K it is. | 17:21 |
| AfC | dato: thanks! | 17:21 |
| jelmer | and that's just in bzrlib.. with a couple of plugins installed it's closer to 15k here | 17:22 |
| AfC | jelmer: wow | 17:22 |
| AfC | jelmer: that's amazing | 17:22 |
| AfC | [not that you really care, but what me write about this is at: http://java-gnome.sourceforge.net/4.0/HACKING.html under "Why bzr?"] | 17:23 |
| AfC | yikes | 17:25 |
| AfC | what I have written* | 17:25 |
| jelmer | AfC: nice | 17:32 |
| jelmer | AfC: btw, "bzr send" should now Do The Right Thing[tm] if you have the child_submit_to setting set to an email address in your main branch | 17:33 |
| jelmer | as alternative to running "bzr bundle" and then manually attaching the bundle and specifying the email address | 17:34 |
| AfC | jelmer: yeah, I'll work out the wording for that down the track. | 17:34 |
| AfC | (is that something that will propagate? No, I believe? Only if someone creates a new branch, right?) | 17:34 |
| AfC | (Will it "remember"?) | 17:35 |
| AfC | (that'd be nice) | 17:35 |
| jelmer | AfC: It retrieves it from the submit branch so there shouldn't be a need to propagate it | 17:36 |
| jelmer | for example: | 17:36 |
| AfC | ah | 17:36 |
| jelmer | bzr branch lp:bzr-gtk; hack-hack; bzr commit -m "foo"; bzr send | 17:36 |
| jelmer | will do the right thing and retrieve the email address from the branch configuration of lp:bzr-gtk | 17:37 |
| AfC | That's what I meant about it working for a new branch; people who have existing repository/branch structures will need to twiddle something manually I expect. | 17:39 |
| AfC | (is what I was asking, that's all) | 17:39 |
| jelmer | AfC: in the scenario I just mentioned, no extra twiddling would be required | 17:39 |
| * Rhamphoryncus checks to see just how well bzr handles merging without known common bases | 18:04 | |
| Rhamphoryncus | I was using a svn checkout initialized as a bzr repository (without the bzr-svn plugin!). Now upstream has an official bzr mirror, so I'm trying to switch to that and eliminate svn.. | 18:07 |
| Rhamphoryncus | aha, it gave up. bzr: ERROR: Revision {('rhamph@base-two-20071105225603-16zlps51e17ghkzl',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x106d8f2c>". | 18:10 |
| Rhamphoryncus | So, can anybody think of an option that gets me most of the history? | 18:10 |
| Rhamphoryncus | assuming my initial checkin had no changes over upstream I should be able to do a patch set and reapply them somehow, right? | 18:15 |
| awilkins | AfC: btw, bzr merge won't let you merge if your tree has diffs from -r -1 | 18:16 |
| awilkins | Hence "do the merge after you.ve finished anything you might happen to be doing" is redundant. | 18:17 |
| AfC | awilkins: Did I imply that it would somwhere? | 18:17 |
| AfC | awilkins: ah.\ | 18:17 |
| AfC | awilkins: well, I'm not really a big fan of Bazaar's error messages. | 18:18 |
| awilkins | Although you could use the point as an opportunity to mention shelve | 18:18 |
| AfC | awilkins: so while you are indeed correct that it is redundant, it doesn't hurt to be attempt to set newbies on the right track habit wise. | 18:18 |
| AfC | awilkins: that in core yet? | 18:18 |
| awilkins | shelve is still in bzrtools AFAIK | 18:19 |
| * AfC only just grabbed 1.3, so I'm not current with the latest state-of-play | 18:19 | |
| awilkins | I switched back to 1.2 from 1.3 on the chance that it might be futzing with the pyrex version of the bzr-svn branch | 18:19 |
| jelmer | Rhamphoryncus: you may be able to use rebase or replay to replay the changes your local branch has on top of the new upstream branch | 18:21 |
| jelmer | awilkins: It would be awesome if we could get that exception handling fixed so 0.4.9 can be released with the pyrex bindings | 18:22 |
| awilkins | jelmer: I was thinking of running the test in Python running attached to a debugger, but I've not got Python 2.5.2 building on Win32 yet ; and I don't have a full 7.1 toolkit | 18:24 |
| awilkins | My best chance so far seems to be using the 9.0 toolkit because you can at least download it as part of the PSDK | 18:24 |
| jelmer | awilkins: Running the tests doesn't make a lot of sense until this problem is resolved | 18:25 |
| jelmer | until then, you'll probably keep getting segfaults | 18:25 |
| awilkins | jelmer: What is so frustrating is that it only segfaults if you run the test suite - the test on it's own passes | 18:25 |
| awilkins | Running the host class is enough to trip the fault | 18:26 |
| awilkins | Sounds memory-flavoured | 18:26 |
| awilkins | something being initialized wrong or a pool going bad or something | 18:27 |
| jelmer | awilkins: that's probably related to it not reporting the test that's segfaulting properly | 18:27 |
| awilkins | So it could be the following test? | 18:28 |
| awilkins | Which DOES throw an exception | 18:28 |
| jelmer | if it prints "ignored exception ..." that's probably a test that's causing a segfault | 18:28 |
| awilkins | WindowsError, as I recall | 18:28 |
| awilkins | Not got my desktop fired up ATM though | 18:29 |
| jelmer | Ignored Exception "WindowsError ..." ? | 18:29 |
| awilkins | Possible | 18:29 |
| awilkins | Give me a few minutes, I'll boot my desktop and run it again | 18:30 |
| arnetheduck | returning to my repo move, once I have my repository converted I'll be keeping a main development branch that I'd like to sync the old svn to, one-way, so that commits to the bzr branch are merged to the svn branch...this should be doable with the bzr-svn plugin, right? | 18:34 |
| awilkins | jelmer: It's an "Access is denied" | 18:35 |
| jelmer | awilkins: hmm, ok | 18:35 |
| jelmer | awilkins: what happens if you run selftest with --one ? | 18:36 |
| awilkins | jelmer: On just that test, or the whole bzr-svn tree? | 18:37 |
| jelmer | awilkins: all of bzr-svn | 18:38 |
| jelmer | it should then quit and print the backtrace as soon as it hits a single exception | 18:38 |
| awilkins | jelmer: fails on test_branch.WorkingSubversionBranch.test_create_checkout | 18:38 |
| awilkins | SubversionException: ('Unable to open an ra_local session to URL', 180001) | 18:38 |
| awilkins | jelmer: This is bzr 1.2, that right? | 18:39 |
| jelmer | awilkins: should be 1.3 | 18:40 |
| jelmer | or bzr.dev | 18:41 |
| awilkins | http://pastebin.ca/953008 | 18:43 |
| jelmer | awilkins: I think that one is probably specific to your environment | 18:47 |
| awilkins | Are these bindings SVN 1.5 specific or are they still 1.4.6 compatible? | 18:58 |
| awilkins | Well, I've built them against the 1.4.6 deps packs, so I guess they should work, eh? | 18:59 |
| jelmer | awilkins: yeah, 1.4 and 1.5 should both work | 19:04 |
| awilkins | jelmer: Arrgh, it works from Eclipse/PyDev but not from my shell | 19:05 |
| awilkins | I HATE Heisenbugs | 19:05 |
| awilkins | Hmm | 19:05 |
| * awilkins diffs plugins tree and source | 19:05 | |
| ubotu | New bug: #205230 in bzr "error message recommending incorrect setting of PYTHONPATH" [Undecided,New] https://launchpad.net/bugs/205230 | 19:06 |
| j1mc | hi there. a group i work with was interested in upgrading our repository to the new pack format, but don't know if it's possible with bzr-svn (which we use) | 19:08 |
| j1mc | here's what i get when i do a bzr info: Checkout (format: dirstate-with-subtree) | 19:08 |
| jelmer | you could upgrade to --pack-0.92-subtree | 19:10 |
| j1mc | jelmer: thanks... i will check into that. | 19:12 |
| j1mc | jelmer: per this page ( http://doc.bazaar-vcs.org/latest/developers/packrepo.html#testing-packs-for-bzr-svn-users ) it says that this kind of subtree support is bleeding edge. is that still accurate? | 19:13 |
| jelmer | j1mc: the format is not experimental but some of the functionality it enables is | 19:14 |
| j1mc | jelmer: could you recommend a page that would detail some of this advanced functionality? i think we use bzr in a pretty straight-forward manner, but it would be good to know what options are more experimental, and what options are better supported. | 19:18 |
| nubbun | Odd_Bloke: thank you for the response to the first PYTHONPATH bug report. | 19:23 |
| jelmer | j1mc: it's fairly simple actually; it enables by reference nested trees | 19:25 |
| jelmer | j1mc: created using "bzr join --reference". If you avoid using that command you should be fine | 19:25 |
| j1mc | jelmer: thanks. | 19:25 |
| TheMonkey | hola | 19:29 |
| TheMonkey | what is the recommended way of setting up a read-only bzr repo over http? | 19:30 |
| james_w | TheMonkey: there should be no setup needed, just serve the branch over HTTP. | 19:30 |
| awilkins | jelmer: Mutters should be showing up in the test log? | 19:31 |
| TheMonkey | so just copy the folder to the server? | 19:31 |
| james_w | TheMonkey: yes, bzr push can do that. | 19:32 |
| TheMonkey | james_w bzr push over http? | 19:32 |
| james_w | TheMonkey: no, bzr push over ssh or something. | 19:33 |
| TheMonkey | ah, yes | 19:33 |
| TheMonkey | is there webDAV support or similar planned to support http for writing, too? | 19:34 |
| TheMonkey | just curious, being a long time svn user | 19:34 |
| james_w | TheMonkey: there is a webdav plugin, but it is marked experimental. | 19:38 |
| jelmer | awilkins: yep | 19:39 |
| TheMonkey | james_w, i see. thanks for the info, i can wait :) | 19:39 |
| awilkins | jelmer: This stack dump lists a line that occurs after a mutter, but the mutter output isn't showing | 19:40 |
| jelmer | awilkins: it may not have been flushed to disk | 19:41 |
| awilkins | jelmer: can you force it, because knowing the value would really help :-) | 19:42 |
| awilkins | jelmer: It's to STDOUT anyway, why would disk flush be a problem? | 19:43 |
| jelmer | mutter doesn't print anything to stdout | 19:49 |
| awilkins | Oh, so the test routine is reading the log file then | 19:49 |
| awilkins | Might it be in the log? | 19:50 |
| jelmer | awilkins: no, it's not reading the log file either | 19:50 |
| jelmer | mutter writes to the log file | 19:50 |
| awilkins | I'm seeing text that is in mutters in my output when I run this test | 19:50 |
| awilkins | Or maybe I'm not | 19:53 |
| * awilkins is going mad | 19:53 | |
| awilkins | Nope, there it is "Guessed branching scheme" - the only place I can find it is in a mutter and it shows in the output | 19:54 |
| jelmer | awilkins: it will remember the mutters for a particular test in memory and output that when the test fails | 19:55 |
| jelmer | after all tests have run | 19:55 |
| awilkins | jelmer: Which is what's puzzling me because the stack dump says line 94, the mutter is on line 93 | 19:55 |
| awilkins | Just before it enters the pyx code | 19:55 |
| jelmer | it should never be printing any of the mutters data to stdout during the test run, only afterwards | 19:55 |
| awilkins | This is afterwards on a --one run | 19:56 |
| jelmer | awilkins: But that one's not crashing then? | 19:56 |
| awilkins | jelmer: No, but it's weird ; if I run it from Eclipse it passes, from the shell it fails | 19:57 |
| jelmer | have you tried running it inside a debugger? | 19:57 |
| awilkins | jelmer: Does "debug as python unit-test" from Pydev in eclipse count? | 19:58 |
| awilkins | jel | 19:59 |
| awilkins | jelmer: I presume the debugging is just calling pyunit | 19:59 |
| jelmer | awilkins: Not really - I mean a C/C++ debugger | 19:59 |
| awilkins | jelmer: I'd have to run it from a python console and attach it, yes? | 20:00 |
| james_w | dato: hi, I think taking the first line of the commit message as special has something to do with it. | 20:10 |
| dato | james_w: sorry? | 20:10 |
| james_w | dato: also the fact that the commit messages are shown much more prominently with git's usual submit message. | 20:10 |
| james_w | dato: re: your blog, sorry. | 20:10 |
| dato | aah, for the "good" part? | 20:11 |
| james_w | yeah, | 20:11 |
| dato | possibly, yeah | 20:11 |
| james_w | I do agree that it is a good thing that is much more common there. | 20:11 |
| jelmer | awilkins: You should be able to start the python debugger in visual studio or sometihng | 20:19 |
| awilkins | jelmer: I have python.exe attached ... now I'm having a hard time running the test from the console | 20:21 |
| awilkins | jelmer: tried "commands.run_bzr(["selftest", "svn", "--one"]) but it stops in __init__ for tests because theres no log file | 20:23 |
| jelmer | awilkins: can't you just attach to "python.exe c:\path\to\bzr.exe selftest svn" ? | 20:25 |
| awilkins | jelmer: Yes, I think so ... C dev is not my usual domain, I'm a Java / VB6 / CSharp coder by trade | 20:30 |
| * awilkins energises | 20:31 | |
| mw-home_ | I've got a question. I use SVN right now, on a remote server. I'm going on vacation and bringing my laptop. Can I make a local bazaar repository based on my svn repository, then do lots of local commits, then when i come back, push it all into the svn repository? | 20:32 |
| awilkins | mw-home_: YEs | 20:32 |
| mw-home_ | thanks! | 20:33 |
| awilkins | jelmer: That test still fails and throws no unhandled exceptions that a debugger catches | 20:33 |
| awilkins | mw-home_: You need the bzr-svn plugin | 20:33 |
| awilkins | jelmer: If you have VS on windows it tends to allow you to attach a debugger JIT just before the process drops dead anyway | 20:34 |
| arnetheduck | awilkins, when recommitting those changes, will each local commit become a svn revision or will all changes go into one svn rev? | 20:34 |
| mw-home_ | awilkins: ok. i'll try to get that plugin. | 20:34 |
| awilkins | arnetheduck: Each mainline revision becomes a single SVN revision | 20:35 |
| arnetheduck | awilkins, nice - that means that I can keep a read-only svn repo in sync with a particular bzr branch with very little effort | 20:36 |
| mw-home_ | i installed bazaar, but i don't have a bzr in my path. i have a baz in my path. are these the same? | 20:39 |
| LeoNerd | No... baz is the arch reimplementation; a totally differnet program | 20:39 |
| james_w | mw-home_: if you are Debian/Ubuntu install bzr instead of bazaar. | 20:40 |
| mw-home_ | thanks | 20:40 |
| jelmer | awilkins: It should be possible to start a process in the debugger | 20:40 |
| awilkins | jelmer: Yes, I've managed that, but it didn't trap anything | 20:41 |
| awilkins | jelmer: For this bug, the default branch_implementations.test_branch.TestBranch.test_create_checkout tests are failing the same way | 20:41 |
| jelmer | awilkins: how do you mean? Running "bzr selftest svn" inside the debugger doesn't make it crash? | 20:41 |
| awilkins | jelmer: No, I was just running with --one and the first fail isn't scary | 20:42 |
| awilkins | jelmer: Running without --one now ; it was attaching to the process before | 20:42 |
| awilkins | jelmer: One problem is I don't think my Python has debug symbols (the Windows build is a bit short of them) | 20:43 |
| awilkins | jelmer: Can Pyrex build with DEBUG on ? | 20:43 |
| awilkins | jelmer: That wasy the extensions at least would have symbols | 20:43 |
| awilkins | jelmer: Well, the debugger traps it, it's in libapr.dll | 20:50 |
| arnetheduck | dato, managed to make a little bash script that creates tags based on the tags | 20:51 |
| awilkins | jelmer: I'll load APR sources into VS and try againb | 20:52 |
| arnetheduck | there are some problems though - it seems that when one does svn copy, it doesn't always note the correct revision that the copy came from - sometimes it uses an old revision + changes made since that revision | 20:52 |
| arnetheduck | or rather, that the revision of the directory isn't always the revision of the entire copy, but older, so if I tag that revision in bzr, it doesn't get all changes... | 20:55 |
| mw-home_ | subversion does checkout, mercurial does clone; what do i do to get a working copy of somebody else's project in bzr? | 20:58 |
| awilkins | jelmer: bzr-svn needs sqlite, yes? | 21:00 |
| james_w | mw-home_: branch (or clone) if you want a proper branch like mercurial, checkout if you just want a working copy for their branch like subversion | 21:02 |
| jelmer | awilkins: yep | 21:02 |
| awilkins | jelmer: I'm having success building the python 2.5.2 sources from scratch, few deps like sqlite missing ATM though | 21:03 |
| awilkins | Also running that APR project in DEBUG now (doh) | 21:03 |
| arnetheduck | jelmer, found a place where bzr-svn loses history when doing svn-import | 21:04 |
| mw-home_ | i'm going to read the bzr for subversion users guide, then try to figure out what I need to do to use both a remote SVN repository and a local bzr repository. | 21:05 |
| james_w | mw-home_: you will want "bzr branch" for the use case that you described above. | 21:06 |
| james_w | you can then take that on holiday, commit as you like, and the when you come back "bzr push" to update subversion. | 21:06 |
| arnetheduck | jelmer, here are the two log entries if you have a second to take a look: http://pastebin.ca/953159 | 21:07 |
| mw-home_ | james_w: i thought I wanted to do a bzr checkout of my svn repository. I should use bzr branch instead? | 21:08 |
| awilkins | mw-home_: Yes, you do. Or even better, create an empty branch (--pack0.92-subtree) and pull into it (if it's a big SVn repo) | 21:09 |
| james_w | mw-home_: if you do checkout then it will update subversion on every commit, if you do branch then it only does it when you push. | 21:09 |
| james_w | so you need network access to the svn server to commit in a checkout, and if you are on holiday this may be | 21:09 |
| james_w | difficult, so I would say branch is better. | 21:10 |
| jelmer | arnetheduck: ? | 21:10 |
| jelmer | arnetheduck: where? | 21:10 |
| james_w | You can switch between them as you like with the "bind" and "unbind" commands though, so the decision is not too big now. | 21:10 |
| arnetheduck | jelmer, the files, those that are added & removed | 21:11 |
| jelmer | arnetheduck: what would you expect it to do? bzr doesn't have a "replace" operation | 21:11 |
| arnetheduck | if you look at the svn log, you'll see they've been replaced (R), but that that new versions came from trunk | 21:11 |
| jelmer | arnetheduck: you'd expect them to be M ? | 21:12 |
| mw-home_ | james_w: thanks! That makes a lot of sense. So, bzr push sounds sort of like merging. | 21:13 |
| arnetheduck | jelmer, I'm not sure what I'd expect them to be...I would expect having full logs for those files though...if you look at the svn log you'll see that the files come from trunk | 21:14 |
| arnetheduck | jelmer, so doing svn log you get the full history...doing bzr log on the same files gives just one revision | 21:15 |
| jelmer | arnetheduck: R in this case is an alias for delete existing file + copy from somewhere else | 21:16 |
| jelmer | arnetheduck: bzr doesn't support copy tracking (yet) | 21:16 |
| jelmer | so there's nothing sane bzr-svn could map this to | 21:16 |
| jelmer | it could do extra processing to infer that there are no other ancestors of those particular files in the current tree, but that would be very expensive performance-wise | 21:16 |
| jelmer | arnetheduck: I would rather instead wait for copy tracking support in bzr to land | 21:17 |
| james_w | mw-home_: merging in bzr is a bit different, you can only push if the two branches haven't diverged. | 21:18 |
| james_w | if you both have commited some revisions then you need to merge in one branch and then push to the other. | 21:18 |
| mw-home_ | james_w: I really should just read the docs. | 21:19 |
| james_w | mw-home_: that would probably help. Also just playing with a couple of branches for a minute might help | 21:20 |
| james_w | mw-home_: just create a throwaway branch with "bzr init foo" then add some files, commit and then branch, push, pull, merge etc. to see what is possible. | 21:21 |
| james_w | then "bzr log" can show you what you did. | 21:21 |
| james_w | Also "bzr viz" from bzr-gtk can show you a graph that may help you to visualise what is going on. | 21:22 |
| arnetheduck | jelmer, but it does track the copy for the directory (and the unchanged files...)? | 21:24 |
| mw-home_ | I installed the bzr-svn package; is there a separate bzr-svn executable, or does it augment the bzr executable? | 21:27 |
| jelmer | arnetheduck: The branch root copy is tracked yes, but that is not a copy in the bzr sense | 21:27 |
| jelmer | mw-home_: You should be able to use most bzr subcommands with subversion urls now | 21:28 |
| jelmer | just like you would with bzr urls | 21:28 |
| mw-home_ | jelmer: my svn repository requires http authentication. the bzr-svn FAQ says that it will use cached userIDs and passwords. but it ain't working for me right now. | 21:29 |
| mw-home_ | I'm doing bzr branch http://myrepository/myproj | 21:29 |
| mw-home_ | And I get a 401 reply (of course). | 21:29 |
| arnetheduck | jelmer, ah, ok...because I guess it's a fairly common situation for svn repos - the above probably happened because if you do a commit, the revision of the directory won't be updated until you do an update (directories generally get the same revision as the revision of the newest sub-entry), so if you do svn copy from a working copy that hasn't been updated, you end up with logs like mine above | 21:30 |
| jelmer | mw-home_: have you forced subversion to cache the password for you? | 21:31 |
| jelmer | mw-home_: what os are you on? | 21:31 |
| jelmer | arnetheduck: I agree it's not as nice as it could be | 21:32 |
| jelmer | arnetheduck: it leads to confusing logs in svn itself as well though | 21:32 |
| mw-home_ | jelmer: yeah, i have a cached password. I can do svn info http://myrepos/myproj and I get data back, and I don't get prompted. I'm using ubuntu gutsy. | 21:32 |
| jelmer | mw-home_: you may have to use svn+http:// rather than http:// | 21:34 |
| arnetheduck | jelmer, indeed - although I must admit it's the first time I look at the log entry of a branch in svn =) I didn't expect it either... | 21:34 |
| mw-home_ | jelmer: yeah, that seems to be working. Thanks! | 21:35 |
| mw-home_ | Will I now have my entire svn repository, history and all, inside bzr now? | 21:35 |
| mw-home_ | or do I only get the most recent (HEAD) revision? | 21:35 |
| arnetheduck | jelmer, in any case, I have a bash script now that reads the revision of the directory and makes a tag for that revision in the trunk so that tags are tagged...let me know if you think it could be useful... | 21:36 |
| arnetheduck | *the tag directory | 21:36 |
| jelmer | mw-home_: you'll get the full history of that particular branch | 21:36 |
| jelmer | mw-home_: I'll update the FAQ | 21:36 |
| mw-home_ | jelmer: wow. | 21:36 |
| jelmer | mw-home_: assuming you used "bzr branch" and not something like "bzr co --lightweight" | 21:37 |
| mw-home_ | jelmer: I did bzr branch. | 21:37 |
| mw-home_ | And so now, can I use bzr commit to do local commits, and bzr push to put stuff into SVN? | 21:38 |
| jelmer | mw-home_: yep | 21:38 |
| mw-home_ | I wish there weren't so many competiting source-control projects. it's intimidating for people that don't want to do a lot of research. | 21:39 |
| arnetheduck | jelmer, dato, thanks for the help! (In my case, I can make it tag correctly by not using the revision of the first common tag/trunk ancestor but the revision that matches the svn revsion of the tag -1) | 21:40 |
| jelmer | arnetheduck: cool | 21:41 |
| jelmer | arnetheduck: Any chance you can link to your script on the wiki | 21:42 |
| jelmer | arnetheduck: It may be useful to others (although hopefully we'll have a more structural solution soon) | 21:42 |
| arnetheduck | jelmer, I can paste it on the wiki if that's ok? I have no good web host to put it on... | 21:44 |
| arnetheduck | jelmer, it's pretty crude too, I really don't like bash scripting and consequently I suck at it... | 21:45 |
| arnetheduck | jelmer, last questing, is there a good way of finding the bzr revid of the last revision on trunk that preceded the revision of a branch? | 21:46 |
| arnetheduck | jelmer, in other words, if I made a tag on svn revision 501, is there a good way of finding the last revision on trunk before 501 (500 in my case since I only commit to trunk)?)? | 21:47 |
| mw-home_ | To pull in from svn into bzr, since I did a bzr branch, do I need to do a bzr pull? | 21:49 |
| james_w | yep | 21:50 |
| mw-home_ | ignore me. i'm trying it out. | 21:50 |
| mw-home_ | it worked! | 21:50 |
| mw-home_ | bzr seems great so far. | 21:50 |
| Manu_ | I would like to know how to specify the drive letter with the file:// protocol under windows | 21:53 |
| mw-home_ | Thanks to everyone that has helped me out. I now know how to use bzr to make local commits and to still use svn. This is a really nice set up. | 21:59 |
| awilkins | jelmer: I now have a working debug build of Python, but joy of joy, it can't seem to load Pyrex modules | 22:03 |
| awilkins | jelmer: Maybe I should rebuild them with the compiler I used to build the python | 22:04 |
| james_w | Manu_: I don't know I'm afraid, have you tried file:///c:/whatever? | 22:13 |
| jelmer | awilkins: Ouch | 22:14 |
| awilkins | jelmer: Par for the course, I fear | 22:14 |
| jelmer | awilkins: Is the difference so big between the code generated by differnet compilers on windows? | 22:14 |
| awilkins | jelmer: Well, the distutils build_ext stuff refuses to build unless you have the same compiler that Python was built on, so I presume there is a good reason | 22:15 |
| Manu_ | james_w: yes it works i forget to add an extra / | 22:23 |
| awilkins | jelmer: Damn, damn, damn. The modules built with VC8 (after inserting enough into the registry to convince distutils that I had it installed...) but they still don't load | 22:24 |
| awilkins | jelmer: Maybe if I put the plugin folder on the pythonpath | 22:25 |
| tca | When I install bzr in my home dir on line with "--home ~", is it only bin/bzr and python/bzrlib that needs to be deleted to uninstall? | 23:10 |
| tca | I'm having seeing this (http://www.pastebin.org/24908) when running bzr log with bzr 1.3, and want to completely reinstall before bugging people more. | 23:12 |
| === bigdo1 is now known as bigdog | ||
| tca | "bzr log --long" fails with the error mentioned above, but with --line or --short it works ok. | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!