Peng | Wait, what about plugins? | 00:00 |
---|---|---|
* Peng wanders off. | 00:00 | |
slangasek | lifeless: there you are then | 00:04 |
jelmer | spiv: Hmm, that's an interesting bug | 00:06 |
jelmer | slangasek: I can't think of a reason a by-value joined tree wouldn't work | 00:07 |
spiv | jelmer: something weird also happened when there were revisions | 00:07 |
spiv | jelmer: it pushed ok, but the merge to trunk caused some sort of property conflict | 00:07 |
jelmer | spiv: That's the bit I mean | 00:07 |
jelmer | spiv: bzr svn-push can't use a clean "svn cp" | 00:07 |
spiv | jelmer: hmm, why not? | 00:09 |
jelmer | spiv: if there is a branch A with tip revision 42 and you're trying to push a branch B that also has tip 42 it has to do a copy of r41 -> /B that replays the changes in r42 | 00:09 |
jelmer | otherwise the two branches actually have a different revision history | 00:09 |
jelmer | A has tip 42 and B has tip 42+1 where rev 1 is en empty commit that changes the branch nick from A to B | 00:10 |
ubotu | New bug: #203376 in bzr "traceback when merging an svn repo with a 'bzr join'ed branch" [Undecided,New] https://launchpad.net/bugs/203376 | 00:11 |
jelmer | slangasek: thanks | 00:12 |
jelmer | spiv: ^ | 00:12 |
spiv | jelmer: hmm, because you can't easily figure out that the tip 42 in B happens to be the same as 42 elsewhere in the repo? | 00:12 |
jelmer | spiv: I can figure that out, but the problem is that B has more revisions than A | 00:13 |
jelmer | the commit that contains the "svn cp" will show up as well | 00:14 |
spiv | Ah, the impedence mismatch, because making a branch in bzr doesn't make a revision. | 00:14 |
spiv | But in svn it does. | 00:14 |
spiv | I think I see. | 00:15 |
jelmer | yep, that's a clearer way of explaining it | 00:15 |
lifeless | so a cp that makes no alterations should not generate a revision in the mappings | 00:15 |
lifeless | :) | 00:15 |
jelmer | lifeless: yep, but there are performance considerations there | 00:16 |
radix | hay guise | 00:21 |
radix | sry for bzr-svn bgz | 00:21 |
spiv | jelmer: I think I'll recommend people like the Twisted guys should just keep using "svn cp" for the initial branch in the repo. | 00:31 |
ubotu | New bug: #203381 in bzr-svn "Error when pushing 0.4.8 to a branch that exists in svn." [Undecided,New] https://launchpad.net/bugs/203381 | 00:35 |
lifeless | jelmer: btw, your versionedfile thunks in bzr-svn will need updating soon :) | 00:38 |
jelmer | spiv: Makes sense | 00:40 |
jelmer | spiv: We could potentially add a create-svn-branch command | 00:41 |
jelmer | lifeless: Which thunks? :-) | 00:41 |
spiv | jelmer: yeah, I was thinking about that. I'm not sure if I like the idea or not :) | 00:41 |
lifeless | jelmer: do you not have an implementation of repo.text_store.get_weave ? | 01:11 |
mxpxpod | I'm trying to convert a git repo to a bzr repo and I'm running into the same problems described here: https://bugs.launchpad.net/bzr-git/+bug/181811 | 01:16 |
ubotu | Launchpad bug 181811 in bzr-git "bzr-git incompatible with certain stgit versions" [Undecided,New] | 01:16 |
mxpxpod | the problem is that when I do the last instruction, it tells me that my converted directory isn't a branch | 01:16 |
lifeless | mxpxpod: I suggest you look into bzr fast-import | 01:25 |
mxpxpod | lifeless: hrmmm... the git in gutsy doesn't provide git-fast-export :( | 01:28 |
poolie | wow i had no idea of http://www.python.org/dev/peps/pep-0292/ | 01:29 |
poolie | least of all that it was in 2.4 | 01:29 |
jelmer | lifeless: nope, don't need it | 01:34 |
jelmer | lifeless: the only place where versionedfile is used is in the fetch code | 01:34 |
lifeless | jelmer: and annotate | 01:39 |
lifeless | jelmer: and repository stacking | 01:39 |
LeoNerd | Random thoughts.... a 'TODO counter' plugin... Keep a track of how many 'TODO' comments I still have in checked-in code | 01:39 |
LeoNerd | Plus maybe a daily email of "Here's some things left to do:" with a few lines of context | 01:39 |
jamesh | poolie: people never expect to find new functionality in the string module :) | 01:43 |
=== _jgreenwa is now known as jetsaredim | ||
jelmer | lifeless: repository stacking isn't supported yet | 01:51 |
jelmer | lifeless: nor is annotate on remote svn files | 01:51 |
lifeless | jelmer: so, to stack we'll need this | 01:57 |
lifeless | yay internode, you go | 01:58 |
lifeless | jelmer: so, to stack we'll need this | 01:58 |
mxpxpod | lifeless: thanks for the tip... I just compiled git from hardy for gutsy and the fast-import worked flawlessly | 01:59 |
jelmer | lifeless: the main reason I haven't bothered to look at it yet is because performance on directories will suck badly | 02:00 |
lifeless | jelmer: I don't think that that is a good reason not to do it ;) | 02:00 |
lifeless | hmm bzrtools complaining | 02:01 |
jelmer | lifeless: well, in either case it's probably better to wait until the new vf api lands :-) | 02:01 |
lifeless | time to edit off the version check again | 02:01 |
jml | jelmer: should I be running released bzr-svn or trunk bzr-svn? | 02:08 |
jml | LeoNerd: I've thought about that. | 02:09 |
jml | LeoNerd: To do it right, that plugin would need to be language-aware. | 02:10 |
jml | poolie: finally heading to yours. | 02:14 |
jelmer | jml: Depends on what version of bzr you'r eusing :-) | 02:15 |
jelmer | jml: 1.2 -> released bzr-svn, bzr.dev -> bzr-svn's bzr branch | 02:16 |
=== kiko is now known as kiko-zzz | ||
=== lamont` is now known as lamont | ||
lifeless | jelmer: btw, why would directories be slow ? | 02:42 |
jelmer | lifeless: there's no way to get all the interesting revisions for a directory | 02:50 |
jelmer | it is possible for a file | 02:50 |
lifeless | dir copies are not explicit ? | 02:50 |
jelmer | lifeless: they are, but there is no call in the svn smart server protocol to retrieve the interesting revisions for a particular dir | 02:51 |
lifeless | garh | 02:55 |
lifeless | about a page of deprecation warnings to go | 02:56 |
jml | ugh. bzr shelve uses __methods | 03:23 |
kgoetz | how can i unlock a repo? i had a commit message window open and my ssh link died | 03:47 |
poolie | kgoetz: bzr break-lock URL | 03:47 |
kgoetz | poolie: i get a reply of "bzr: ERROR: The lock for '/home/kgoetz/public_html/dansitev01' is in use and cannot be broken." | 03:48 |
poolie | hm | 03:52 |
poolie | is there still a bzr process running on that machine by any chance? | 03:53 |
kgoetz | let me check | 03:53 |
kgoetz | yes there is. theres a `bzr ci` running still | 03:54 |
kgoetz | poolie: thanks for pointing that out - killed the process and the break-lock worked | 03:56 |
poolie | you're welcome | 03:56 |
igc | night all | 04:45 |
lifeless | igc: night | 04:56 |
lifeless | igc: you jetlagged ? | 04:57 |
poolie | and i shold be here | 05:45 |
poolie | lifeless: symbol_versioning patch sent | 05:58 |
lifeless | thanks | 05:59 |
lifeless | poolie: k, I'm done for the day; this is I think the hardest of the apis to adjust, because of the ghost implications, and its nearly done. | 06:11 |
lifeless | poolie: couple of failing tests still | 06:11 |
lifeless | jml: whats wuhi ? | 06:52 |
jml | lifeless: We Haven't Used It | 06:53 |
jml | I could *swear* I've read it in some agile manifesto before. | 06:53 |
lifeless | ah | 06:59 |
TFKyle | hmm, wouldn't that be whui? | 07:02 |
jml | TFKyle: yes. there was a typo somewhere along the way. | 07:22 |
lifeless | I object to that, I'm not a typo. I'm a hoomarn bean | 07:27 |
i386 | lifeless: have you seen this? http://code.google.com/p/python-safethread/ | 07:32 |
bob2 | "base (single-threaded) throughput is only around 60-65% that of normal CPython" | 07:37 |
lifeless | i386: no, I haven't | 07:52 |
=== mwhudson__ is now known as mwhudson | ||
bob2 | bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ermurri/vc-bzr/emacs22.1/.bzr/repository/lock): Transport operation not possible: http does not support mkdir() | 11:56 |
luks | you can't push over http | 11:57 |
bob2 | that was a pull | 11:57 |
luks | no idea then | 11:57 |
james_w | bob2: are you running the latest version? | 11:57 |
bob2 | 3295 | 11:58 |
bob2 | ah, it was a heavy weight checkout | 12:02 |
james_w | ah, ok. | 12:04 |
=== AnMaster_ is now known as AnMaster | ||
=== mrevell is now known as mrevell-lunch | ||
=== FreeNode is now known as herb | ||
siretart | does anyone know if a new bzrtools release is scheduled to appear 'soon'? | 12:56 |
james_w | hi siretart | 13:06 |
james_w | I haven't heard. | 13:06 |
james_w | Aaron is normally pretty prompt | 13:06 |
siretart | hi james_w | 13:12 |
siretart | I've now built a debian package for myself based on what's currently in bzrtools.dev | 13:12 |
siretart | however the testsuite (not run during package build) fails | 13:13 |
siretart | I've considered uploading it to debian to get bzrtools and bzr-builddeb installable again | 13:13 |
dky | i heard as part of emacs discussions, some performance improvements have been proposed or checked in? | 13:18 |
dky | I am interested in testing for performance, could someone give me extra information how to test bzr for performance | 13:19 |
=== mrevell-lunch is now known as mrevell | ||
bob2 | 'bzr --profile command whatever' might be of use | 13:28 |
=== herb is now known as herb__ | ||
=== herb__ is now known as herb | ||
=== spiv_ is now known as spiv | ||
mbt | Is there some trick to being able to use bzr normally on an NFSv4 mounted home directory? | 14:35 |
=== kiko-zzz is now known as kiko | ||
james_w | mbt: what do you mean normally? | 14:40 |
mbt | Without errors... Nearly everything I do is accompanied by an "bzr: ERROR: [Errno 5] Input/output error" when using it on an NFSv4-mounted home, but when on the local filesystem, I do not get this error. | 14:41 |
mbt | For example, I get that error when I bzr diff | 14:41 |
mbt | or bzr status | 14:41 |
james_w | mbt: the error traceback would be useful to see. | 14:42 |
mbt | james_w: Is there a way to make it generate one? | 14:42 |
mbt | It just shows the Errno 5 message. | 14:42 |
james_w | mbt: bzr -Derror diff | 14:42 |
mbt | james_w: http://pastebin.com/d1561bfcd | 14:43 |
james_w | mbt: ok, so it's having some problems removing the lock. | 14:46 |
mbt | Should I go ahead and file a bug, then? I would presume that it is supposed to work on an NFS-mounted home, right, or is that outside of what bzr is expected to do? | 14:48 |
james_w | mbt: is https://bugs.launchpad.net/bzr/+bug/137387 it? | 14:54 |
ubotu | Launchpad bug 137387 in bzr "UserWarning: lock not released cluttering user output" [High,Triaged] | 14:54 |
igc | morning | 14:56 |
james_w | hi igc | 14:56 |
mbt | james_w: It might be, but I am not sure. | 14:56 |
mbt | james_w: Let me see if I can coax bzr into giving me more details | 14:57 |
igc | hi james_w | 14:57 |
james_w | igc: fast-import broke for me. I haven't had time to debug it yet. | 14:59 |
igc | james_w: just send me the traceback | 14:59 |
igc | I added tag support last night | 14:59 |
igc | well, lightweight tags at least | 15:00 |
igc | might be that? | 15:00 |
mbt | Is there a way to generate a log file as is shown in that bug report, james_w? I can't seem to find it. | 15:00 |
james_w | igc: no, it was before that. | 15:00 |
james_w | mbt: ~/.bzr.log | 15:00 |
james_w | igc: it's bzr-fast-export | bzr fast-import on bzr.dev | 15:01 |
bratsche | Is it possible with bzr to work with multiple branches out of one directory and switch between them, similar to git? | 15:01 |
igc | james_w: ok, I'll try that. How far though was it previously? | 15:01 |
bratsche | Or actually, I should just state what my problem is first and see if there is any better way to do what I'm doing in bzr: | 15:02 |
james_w | igc: it did all bzr-fast-export could export. | 15:02 |
james_w | igc: let me upload the dump for you. | 15:02 |
bratsche | We have a pretty large codebase in bzr at work now, and each time I make a branch it takes a long time to branch the remote mainline to a local directory because it's pulling down all the source. | 15:03 |
igc | bratsche: are you using a shared repository locally? | 15:03 |
igc | it's highly recommended to do that | 15:04 |
bratsche | No, the shared repo is on the server. | 15:04 |
bratsche | Let me search for how to do a shared repo locally. | 15:04 |
igc | bratsche: you definitely want a shared repo locally as well | 15:04 |
mbt | it looks like that might be the bug... though the workaround in it does not work, and I still get problems... sigh | 15:04 |
james_w | bratsche: a shared repository is just a way of sharing data between branches so you can do it anywhere. | 15:04 |
igc | it's covered in the User Guide | 15:04 |
bratsche | igc: Right now I do: bzr branch <remote-mainline> <remote-branch-url> ; bzr checkout <remote-branch-url> | 15:05 |
james_w | bratsche: ouch | 15:05 |
bratsche | igc, james_w: Awesome, thanks very much! I'll search for how to set that up. | 15:05 |
james_w | are remote-mainline and remote-branch-url sharing a shared repo? | 15:05 |
bratsche | james_w: Yes. | 15:05 |
james_w | igc: http://jameswestby.net/scratch/bzr-export.txt | 15:06 |
james_w | though it is about 20MB, so you may prefer to just generate it locally. | 15:06 |
igc | james_w: I'll generate it locally | 15:06 |
igc | It's just bzr-fast-export.py bzr.dev, right? | 15:07 |
james_w | yep. | 15:07 |
Odd_Bloke | Afternoon. | 15:08 |
bratsche | So I want to do like: bzr init-repo my-local-repo ; cd my-local-repo ; bzr branch <remote-mainline> ; bzr checkout <remote-mainline> | 15:09 |
bratsche | To setup my local shared repo? | 15:09 |
mbt | http://pastebin.com/d2f120d12 -- james_w, should I add that info to bug 137387? | 15:09 |
ubotu | Launchpad bug 137387 in bzr "UserWarning: lock not released cluttering user output" [High,Triaged] https://launchpad.net/bugs/137387 | 15:09 |
bratsche | And then when I create new branches, I would branch from the local repo? | 15:09 |
james_w | hi Odd_Bloke | 15:10 |
Odd_Bloke | bratsche: You only need to do one of branch or checkout there. | 15:11 |
luks | bratsche: repositories are just an optimalization, you can ignore them and just use the workflow you had before | 15:11 |
james_w | mbt: yeah probably | 15:11 |
luks | but with a repo it won't download everything | 15:11 |
james_w | mbt: if you could debug why these errors occur that would be great. | 15:11 |
luks | because you already have the revisions | 15:11 |
bratsche | So I create my repo, and just checkout <remote-mainline>? | 15:12 |
Odd_Bloke | james_w: o/ | 15:12 |
Odd_Bloke | bratsche: Within the repo, yeah. | 15:12 |
bratsche | Odd_Bloke: What about when someone else at work posts a branch on the server, and I want to switch over to view it? | 15:13 |
luks | bratsche: switch the existing checkout? | 15:14 |
luks | if so, 'bzr switch <other-remote-branch>' | 15:14 |
bratsche | Okay, thanks. | 15:14 |
Odd_Bloke | bratsche: Or you can checkout that branch into a different directory in the repository. | 15:14 |
bratsche | I'd better go read some more about repos rather than ask all of this here. | 15:14 |
bratsche | Sweet. | 15:14 |
bratsche | Thanks everyone. | 15:15 |
james_w | bratsche: there is also "bzr help repositories" that explains a little bit | 15:16 |
mbt | james_w: I would love to help debug it, but I am not sure where I would even start on it. I know next to nothing about file locking and filesystems. All I really know at this point is that bzr on local reiserfs works perfectly, on nfsv4, it doesn't. | 15:17 |
mb1 | arrgh. | 15:20 |
=== mb1 is now known as mbt | ||
mbt | Was my last msg about reiserfs/nfs/etc received? | 15:21 |
james_w | yeo | 15:21 |
james_w | well I'm not sure if it's a locking problem in terms of flock() etc., or just the way that we are creating lockdirs | 15:22 |
mbt | k wasn't sure if that actually got out before my client crashed lol | 15:22 |
james_w | I don't know the lock code at all though I'm afriad. | 15:22 |
mbt | Well, I can try to poke around it at some point this evening, but I have to finish setting up my network, because it's been restructured (which is actually how I found this issue lol). | 15:23 |
spiv | jelmer: when is the 0.4.8 release? :) | 15:25 |
=== ja1 is now known as recover | ||
=== recover is now known as ja1 | ||
=== ja1 is now known as jma | ||
=== jma is now known as jam | ||
awilkins | jelmer: Should be able to have another crack at building that binding on Friday | 15:38 |
awilkins | jelmer: A bit busy until then. | 15:38 |
jelmer | spiv: I'm trying to get it done before 1.3 | 15:39 |
jelmer | spiv: I hope to get the pyrex stuff in before then | 15:39 |
ubotu | New bug: #203598 in bzr "Bzr should remember all locations and provide nicknames" [Undecided,New] https://launchpad.net/bugs/203598 | 15:56 |
spiv | jelmer: ah, ok. | 15:57 |
spiv | jelmer: personally I'd probably release 0.4.8 without pyrex, and if you happen to make a 0.4.9 (or even 0.5.0...) with pyrex a week later, then that's fine. | 15:59 |
spiv | jelmer: but I do sympathise with wanting to minimise churn | 15:59 |
spiv | jelmer: would you like other people to test your pyrex branch, btw? | 16:08 |
jelmer | spiv: well, there is one bug which still needs fixing | 16:14 |
jelmer | spiv: do you have any pyrex experience? | 16:14 |
spiv | jelmer: a little bit | 16:15 |
jelmer | spiv: I'm trying to get pyrex to not return NULL from a cdef function when an exception is being raised | 16:16 |
hsn_ | can someone please tell me again command for changing branch into lightweight checkout? | 16:16 |
james_w | hsn_: I think reconfigure can do it | 16:17 |
=== ja1 is now known as jam_ | ||
jelmer | spiv: that's the main bit that's preventing the pyrex branch from working | 16:18 |
hsn_ | james_w: yes, thats right | 16:19 |
ubotu | New bug: #203607 in bzr "bzr unable to upgrade pack-0.92 to rich-root-pack format" [Undecided,New] https://launchpad.net/bugs/203607 | 16:30 |
* lamont has a stupid-bzr question.. | 16:34 | |
lamont | hrm.. | 16:34 |
lamont | nm | 16:34 |
awilkins | The stupid-bzr plugin isn't compatible with the current bzr version I'm afraid | 16:36 |
=== kiko is now known as kiko-fud | ||
jam_ | hmm.. that was a very long question | 17:30 |
jam_ | I seem to have missed it completely :) | 17:30 |
dennda | Hey | 17:31 |
dennda | I am just trying to branch a remote svn repository (over https) | 17:31 |
dennda | bzr-svn is installed | 17:32 |
dennda | this is the result: http://paste.pocoo.org/show/34207/ | 17:32 |
Odd_Bloke | jelmer: ^^^ | 17:35 |
james_w | dennda: can you try bzr branch svn+https://svn.example.com/myrepo | 17:38 |
lifeless | moin | 17:49 |
dennda | james_w: thanks, that works | 17:49 |
dennda | james_w: but how to tell bzr how to push to that location? | 17:49 |
dennda | nevermind | 17:50 |
dennda | just figured it out | 17:50 |
dennda | thanks | 17:50 |
jelmer | dennda: see the FAQ | 18:03 |
jelmer | dennda: never mind, I was reading backlog | 18:04 |
ubotu | New bug: #203643 in bzr "'bzr status' crashes with MemoryError" [Undecided,New] https://launchpad.net/bugs/203643 | 18:11 |
lopio | hi | 18:41 |
lopio | i'd like to propose bazaar instead of cvs but there are 2 question about it.Could you help me ? | 18:42 |
james_w | sure | 18:42 |
lopio | 1) it seems impossible to retag single files (example i need to create a package with old files labelled AAA and i want to add 2 files in HEAD) | 18:44 |
=== kiko-fud is now known as kiko | ||
james_w | lopio: sorry, I don't understand the question, could you explain it a little more please? | 18:45 |
lopio | in CVS i'll extract old label AAA and i'll force a retag AAA on the 2 files | 18:45 |
lopio | ok | 18:45 |
luks | lopio: no, bzr doesn't have per-file tags | 18:45 |
luks | (or per-file revisions, like cvs) | 18:46 |
luks | in bzr you would normally branch of the tag AAA and then merge the changes to those 2 files from HEAD | 18:47 |
lopio | i see luks but in this case i'll have a new branch forever | 18:48 |
luks | is that a problem? | 18:49 |
lopio | it is a problem when you have a schema with central repository.... | 18:50 |
james_w | lopio: if you want the old versions of two files then you can use revert to get them, and then commit to include them in your current HEAD | 18:50 |
luks | well, tag in bzr applies to the whole tree | 18:50 |
luks | so if you don't have such tree in your branch, you need to create it | 18:51 |
lopio | ok | 18:51 |
lopio | this is not a blocking problem -) | 18:51 |
lopio | Now a real problem -( | 18:51 |
luks | but generally you would have this problem with any VCS that isn't CVS | 18:52 |
luks | I don't know of any other VCS that works on file basis | 18:52 |
lopio | CVS is old but is able to manage CRLF | 18:52 |
lopio | and this is a real problem for us | 18:53 |
abentley | siretart: I'll try to have it out this evening. | 18:53 |
lopio | we have a central CVS repository and we are able to co and commit in XP and HP both | 18:53 |
lopio | this is because in CVS you have to specify -kb parameter when you add an exe file | 18:54 |
lopio | in this way when you checkout under XP a CR is added to files different from exe (and removed during commit) | 18:55 |
james_w | lopio: we want to add support for line endings, but it is not done yet. | 18:56 |
lopio | this is a strong limitation i think -(((((((((( | 18:57 |
lopio | It seems a marvellous versioning system so i hope some people could add this feature as soon as possible | 19:00 |
lopio | keep up the good work!!! Thank you very much...see you later..bye | 19:01 |
igc | james_w: fyi - fast-import is better now wrt renaming handling | 19:05 |
igc | a bug still exists though | 19:06 |
igc | it now gets a lot further on your bzr.dev export but not all the way through | 19:06 |
igc | I'm moving onto some other stuff now so it might be a day or so before I get back to this | 19:07 |
=== luks_ is now known as luks | ||
mamato_ | anyone know of tool to completely remove files from my bzr history? | 20:01 |
james_w | mamato_: no such tool exists yet I'm afraid. | 20:02 |
mamato_ | weird... | 20:04 |
mwhudson | bzr strongly discourages rewriting history | 20:07 |
mamato_ | hmm... should have maybe sticked to rcs then :S | 20:11 |
mwhudson | you might be able to use rebase, especially if the file hasn't changed much over history | 20:12 |
* mamato_ strongly encourages cleaning up one's crap when needed | 20:12 | |
mwhudson | i guess we could have an argument about that | 20:13 |
mwhudson | but i can't really be bothered | 20:13 |
nevans | mamato_: the only compelling use-case I can see for changing history in a good VCS is when "sensitive" data has accidentally gotten into the repo | 20:17 |
nevans | e.g. passwords | 20:17 |
mamato_ | i need versioning for personal code... i'm the only user... for the first project i used it, i realized that i had accidentally checked in tons of images which dont need versionning... couldn't back up my branch to the internet like i wanted... had to loose all my change history weeks after... if a 'good VCS' doesn't allow it, maybe that's not what i need... | 20:23 |
mamato_ | all i want is a 'useful vcs' that corresponds to my needs... | 20:25 |
nDuff | mamato_, fastexport + edit + fastimport? | 20:25 |
nDuff | mamato_, that's not entirely unlike the SVN methodology of dumping to XML to edit history. | 20:25 |
james_w | nDuff: I expect there will be a tool to filter a fast-export stream at some point. | 20:27 |
nevans | okay... wanting to trim disk usage in a personal-use only project... that's another compelling use-case. ;-) | 20:27 |
nevans | (I don't deal with personal-use projects much... except for /etc and ~/ ) | 20:28 |
=== kiko is now known as kiko-afk | ||
* mamato_ can't find fastexport info on google :S | 20:29 | |
* mamato_ found fastimport! | 20:30 | |
nDuff | mamato_, https://lists.ubuntu.com/archives/bazaar/2008q1/038391.html | 20:30 |
nDuff | mamato_, ...not saying that's the most current location. | 20:31 |
nevans | it looks like git already has a tool for filtering fast-export streams: http://www.kernel.org/pub/software/scm/git-core/docs/git-filter-branch.html | 20:31 |
nDuff | nevans, looks to me like you'd need to actually import the stream into a git repository to use that. Which, granted, wouldn't be the end of the world. | 20:33 |
mamato_ | nevans: thx for the info... | 20:35 |
mamato_ | i hear git is quite nice too... will look into it more closely... except for this, have had good experience with bzr though :( | 20:38 |
mamato_ | how do you .bzrignore some sub-directories? | 20:51 |
spiv | mamato_: have you seen http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#ignoring-files ? | 20:51 |
mamato_ | yep | 20:52 |
mamato_ | but didn't find info | 20:52 |
mamato_ | spiv? it only deals with ignoring files... not directories... and specifying directory doesn't seem to work | 20:55 |
spiv | mamato_: hmm, I'd expect ingoring a directory to work | 20:57 |
spiv | mamato_: it seems to work as I'd expect for me: http://rafb.net/p/nyFWyY31.html | 20:58 |
spiv | mamato_: perhaps you've already added the file? "bzr ignore" won't ignore a file that's already versioned. | 21:01 |
NfNitLoop | I regularly ignore directories. | 21:01 |
spiv | mamato_: so you may need to use "bzr rm --keep" on those files. | 21:01 |
mwhudson | damn, i wish i had a spare time machine so i could work on bzr's graph operations | 21:01 |
* spiv -> afk | 21:01 | |
mamato_ | weird... your test case works but doesnt work with my branch... and not already versioned... going back to figuring it out... | 21:04 |
mamato_ | ah... parent dir (whihc i want to ignore) IS versionned... makes sense... | 21:05 |
spiv | jelmer: I think for the exceptions returning NULL issue you want "cdef int spam() except -1:" (http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/basics.html#ExceptionValues) | 21:27 |
ubotu | New bug: #198092 in bzr "Should tell the user to run bzr launchpad-login before push lp:" [High,Triaged] https://launchpad.net/bugs/198092 | 22:07 |
jelmer | spiv: that doesn't work, since an SVN error is a pointer | 22:07 |
jelmer | spiv: pyrex only supports "except NULL" but NULL in this case actually is the only return value that means there's no error | 22:08 |
AfC | jelmer: got a sec | 22:13 |
AfC | ? | 22:14 |
james_w | hi AfC | 22:17 |
* AfC waves | 22:20 | |
lifeless | jelmer: don't try to use the same function for two different protocols then :) | 22:39 |
lifeless | jelmer: the one directly exposed to python _must_ use the python conventions - return NULL -> there is an error set | 22:40 |
lifeless | jelmer: you probably need to wrap the svn_ra functions with ones that invert the return code to do what you need | 22:40 |
jelmer | AfC: hi | 22:41 |
jelmer | lifeless: hi | 22:41 |
jelmer | I already have one level of indirection - I register a pyrex callback that can calls a python function | 22:42 |
AfC | jelmer: I know we almost talked about this the other day, but I was wondering if you have any [further] specific insight into whether or not two different people with different Subversion account names could use a bzr-svn branch once created? | 22:43 |
AfC | jelmer: ie, it took me the better part of 9 days to create a bzr-svn branch of GTK. I'd like to share that with someone else to save that being (through no fault of bzr-svn's) someone's first impression of Bazaar | 22:44 |
lifeless | AfC: you can share that just fine | 22:44 |
lifeless | AfC: the svn account name is not part of the created bzr branch | 22:45 |
AfC | but obviouly they have a different [ssh] account to talk to GNOME's Subversion repository, so if I either a) publish the resultant Bazaar branch, or b) tarball the branch + repository | 22:45 |
AfC | and pass it to someone, whether or not it would work | 22:45 |
jelmer | AfC: Yes, two people with the same name could share a bzr-svn branch | 22:45 |
AfC | jelmer: different usernames | 22:45 |
jelmer | AfC: yes, no problemo | 22:46 |
AfC | jelmer: ah. AWESOME | 22:46 |
AfC | Then I shall get us hosting a series of such branches as a community service. | 22:46 |
poolie | good morning | 22:47 |
AfC | jelmer: so I assume all that will have to happen is that when it comes time for them to commit and push back to the upstream Subversion repo is to do | 22:47 |
AfC | jelmer: bzr push --remember svn+ssh://their_user_name@svn.gnome.org/svn/gtk+/trunk | 22:48 |
AfC | jelmer: and they'll be all set | 22:48 |
jelmer | AfC: yep | 22:48 |
AfC | Beautiful | 22:48 |
jelmer | AfC: Hopefully shallow branches can help avoid the long time it takes to get an initial branch | 22:48 |
jelmer | lifeless: What's the status on shallow branches? | 22:48 |
AfC | It was interesting to hear Carl report his experience that: | 22:48 |
AfC | "The *moment* I see a Subversion URL from someone, even before I think I might want to hack on it, I just feed it to git-svn and let it run on a server, because I know it'll take forever, but eventually it'll be done and I'll have a branch to use from Git if I want to" | 22:49 |
AfC | (And they do then share those around, which also gave me the idea of seeing if we could too. Awesome) | 22:50 |
jelmer | AfC: 9 days seems like a lot of time, btw | 22:50 |
hsn_ | what kind of storage is more resistent to corruption? packs or knits and what kind of storage has better recovery tools? | 22:50 |
jelmer | I also have a gtk+ trunk import here, and afaik it took less than a day | 22:50 |
AfC | (well, I had intermittent network access and a not-svn-HEAD to deal with) | 22:51 |
lifeless | hsn_: packs | 22:51 |
lifeless | jelmer: they work but not with the smart server | 22:51 |
lifeless | jelmer: I'm fixing the root issue preventing them working with the smart server at the moment | 22:52 |
awilkins | Go-go shallow branches! | 22:52 |
awilkins | Also go go pyrex bindings | 22:53 |
jelmer | lifeless: ah, cool | 22:53 |
lifeless | jelmer: which is the versionedfiles rework | 22:58 |
lifeless | jelmer: because you need to be able to stack on historical data | 22:58 |
lifeless | poolie: status for me -> versionedfiles at full steam | 22:59 |
poolie | toot toot! | 23:00 |
poolie | enjoy | 23:00 |
jml | I just tried to branch a Subversion branch into a pack repo and got this: bzr: ERROR: Repository KnitPackRepository('file:///home/jml/Code/Pimlico/jana/.bzr/repository/') is not compatible with repository SvnRepository('http://svn.o-hand.com/repos/jana') | 23:08 |
jml | I'm using bzr-svn trunk and Bazaar 1.2 | 23:08 |
awilkins | jml: You need rich-root-pack | 23:09 |
jml | awilkins: that in 1.2? | 23:10 |
awilkins | jml: Was in .092 AFAIK | 23:10 |
awilkins | 0.92 | 23:10 |
* jml tries | 23:11 | |
jml | OK. Now I'm getting SubversionException: ("PROPFIND request failed on '/repos/jana/branches/jana'", 175002). This is odd, because I can check it out just fine with the svn client | 23:12 |
awilkins | jml: Is it a password protected repo? | 23:13 |
jml | awilkins: no. | 23:13 |
jml | awilkins: or, at least, it's not protected for reading. | 23:13 |
awilkins | Are you using a release or the tip of a branch (of bzr-svn) | 23:13 |
jml | awilkins: tip of http://bazaar.launchpad.net/~jelmer/bzr-svn/trunk/ | 23:14 |
awilkins | I've never used that..... try the 0.4.8 branch | 23:15 |
awilkins | I presume you've installed patched bindings, etc? | 23:16 |
jml | I'm fairly sure I have. | 23:17 |
jml | maybe I'll try the packaged version. | 23:18 |
jelmer | bzr-svn will give you a warning if you're not using the patched bindings | 23:18 |
jml | jelmer: so, any ideas? | 23:38 |
lifeless | jml: whats a jana? | 23:38 |
jelmer | jml: have you tried the 0.4.8 branch? | 23:39 |
jml | jelmer: no, I'll have a look at that. | 23:39 |
jml | lifeless: it's apparently a japanese word. the project is the openedhand guys' new calendar thingummy | 23:39 |
* awilkins thinks of Jana of the Jungle | 23:40 | |
=== kiko-afk is now known as kiko | ||
lifeless | fingers crossed, step 1 may be done. whew. | 23:55 |
poolie | lifeless: call me sometime today, at your convenience | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!