| === mw is now known as mw|out | ||
| toojays | Hi bzr people! Can somebody please tell me how to do a partial commit in bzr? | 02:38 |
|---|---|---|
| toojays | If I were using git, I would do "git add -p". | 02:39 |
| jelmer | toojays, just specify the path | 02:39 |
| toojays | Can bzr do something like this? | 02:39 |
| jelmer | toojays, bzr commit <path> | 02:39 |
| toojays | jelmer: The changes I want to commit separately are in the same file. | 02:39 |
| toojays | One set of changes I will want to merge to another branch, one set I will not. | 02:40 |
| toojays | But they are in the same file. | 02:40 |
| jelmer | ah, you'd like bzr to prompt you about each chunk of changes? | 02:40 |
| toojays | Yeah, I guess that's the only UI I know of to do what I want. | 02:41 |
| fullermd | I think somebody wrote a plugin... bzr record or something. | 02:41 |
| fullermd | You could also use shelve to set aside the bits you don't want, commit, then bring them back. | 02:42 |
| toojays | Shelve . . . yeah, that sounds like a workaround I could use. | 02:42 |
| toojays | This makes me think . . . is there a page for people coming to bzr from other dvcs systems, which compares how to do similar operations? | 02:43 |
| toojays | I have been using git a lot at work, but am using bzr at home . . . so I'm pretty fluent with git, but have only been doing "easy" stuff with bzr so far. | 02:43 |
| fullermd | Well... the people wanting that particular thing are usually the darcs people ;) | 02:44 |
| fullermd | Hence 'record'. | 02:44 |
| fullermd | Ah, 'interactive'. Renamed post-loom, I guess. | 02:45 |
| fullermd | https://launchpad.net/bzr-interactive | 02:45 |
| toojays | fullermd: thanks, that sounds like it will do what I want. | 02:47 |
| markh | jelmer: bzr-svn is still reporting as '0.4.13dev0' - is that likely to change for a 1.7 release? | 04:23 |
| === sdboyAAAAAR is now known as sdboyer | ||
| planetcalls | hi. I am pretty new to bazar. Mini tuts on website show command line way of doing things. Do we have any UI or shell hooks like SVN for bazar ? | 05:31 |
| mlh | for windows or linux? | 05:37 |
| mlh | there's a few in progress | 05:37 |
| mlh | check the website | 05:37 |
| mlh | there's TortoiseBZR in progress, specifically for windows | 05:38 |
| markh | planetcalls: if you are on windows, try the 1.7rc2 build rather than 1.6 - the GUI stuff is much more polished there. | 05:38 |
| mlh | there you go -- straight from the source :-) | 05:39 |
| markh | :) | 05:39 |
| planetcalls | markh, thanks. From the examples and documents it seems as if bazar is having only the command based binaries. | 05:40 |
| markh | planetcalls: its very much a current work in progress, so the examples and docs lag a little still | 05:40 |
| markh | planetcalls: but that also means it is so new that there are issues and things not implemented. It is no where near as mature as TortoiseSVN yet. | 05:41 |
| markh | its functional though | 05:41 |
| planetcalls | yea that is obvious. I am not going to give up Tortoise anytime soon but wanted to give distributed vcs a try | 05:42 |
| planetcalls | just found TortoiseBzr....sounds it would be easier to adopt bazar in near future | 05:44 |
| markh | planetcalls: yeah, the most recent TortoiseBzr is in the bzr 1.7rc2 binary on launchpad | 05:50 |
| markh | planetcalls: but it also includes a plugin which allows you to use a GUI from the command line - eg, "bzr qci" will show a graphical version of "bzr ci" - ie, to do a checkin | 05:51 |
| planetcalls | ok thanks......now downloading | 05:52 |
| _zou | after command "bzr update", I got following messages: | 05:56 |
| _zou | Unable to obtain lock file:///cygdrive/d/work/OpenSrc/gnash_bazaar/trunk/.bzr/branch/lock | 05:56 |
| _zou | locked 37 hours, 51 minutes ago | 05:57 |
| _zou | Will continue to try until 13:00:39 | 05:57 |
| _zou | anyone knows how to solve this? | 05:58 |
| markh | _zou: 'bzr break-lock' | 06:01 |
| markh | _zou: but you should probably also upgrade your bzr to a non-cygwin one - one of the 1.6 or 1.7 binaries would be good. | 06:02 |
| _zou | thanks, trying now. | 06:02 |
| _zou | does it work on windows? | 06:02 |
| _zou | 'bzr break-lock' works, update again now. | 06:03 |
| markh | _zou: yeah, 1.6 and 1.7 builds for windows are looking good. | 06:06 |
| markh | if that is what you were asking :) | 06:06 |
| _zou | thanks, I'll try it later. | 06:07 |
| _zou | 'bzr update' | 06:08 |
| _zou | now it prints '/ 0/0', and no progress. | 06:09 |
| _zou | is there anyway that I can check if the connection is successful? | 06:10 |
| _zou | connection to bzr server. | 06:10 |
| _zou | no timeout message, no error message, 'bzr update' just stalled. | 06:12 |
| markh | _zou: it can sometimes appear to do that. Check .bzr.log and you might see activity | 06:19 |
| markh | in your "my documents" folder | 06:19 |
| markh | but let it go - the problem is in the progress reporting rather than anything more serious | 06:20 |
| markh | I actually opened a bug on that - it mentions the 'branch' command but I think its the same - bug 264615 | 06:21 |
| ubottu | Launchpad bug 264615 in bzr "progress bar for pull does nothing until near completion" [Medium,Triaged] https://launchpad.net/bugs/264615 | 06:21 |
| markh | (oops - mentions 'pull' :) | 06:22 |
| _zou | markh: yes, I found the file under "my documents", but no message for today. | 06:23 |
| _zou | There are some old messages. | 06:23 |
| markh | hrmph | 06:23 |
| markh | 'up -v' might help - but I'd let it go in the hope it actually working | 06:24 |
| markh | obviously not forever, but many minutes isn't unusual if there are many revisions to pull. | 06:24 |
| _zou | I wait a whole morning last time, still no progress or unfinished. Then I used "ctrl + C" to break the command. That's why I need the 'bzr break-lock' command today. | 06:33 |
| _zou | yes, there are many revisions. | 06:33 |
| _zou | I haven't update for a long time. | 06:33 |
| markh | hrm - 'up -v' might give some insight, but it might not :( if its connecting via ssh it might be strangeness related to that somehow | 06:37 |
| === beaumonta is now known as abeaumont | ||
| _zou | markh: "bzr up -v" also printed "- 0/0" and stalled here. Thanks anyway, might be a network problem here. | 08:33 |
| Leonidas | hi | 08:49 |
| Spaz | hello | 08:50 |
| Leonidas | chich change is needed so that I get a file called 'TREE_ROOT' in iter_changes? | 08:50 |
| Leonidas | s/chich/which/ | 08:50 |
| Leonidas | I see that the empty path has the id TREE_ROOT, but how to make a change to the empty path that is tracked using bzr? | 08:56 |
| mwhudson | you don't, i think | 08:58 |
| Leonidas | mwhudson: so why bzr.dev has such changes? | 09:00 |
| mwhudson | maybe i think wrong then :) | 09:00 |
| mwhudson | but bzr.dev has a long and rather more ... eccentric ... history than most branches | 09:00 |
| mwhudson | (like having a revision with revid "A") | 09:00 |
| mwhudson | Leonidas: i guess you can look at the revisions in bzr.dev that appear to modify TREE_ROOT, right? | 09:01 |
| Leonidas | mwhudson: I currently don't know how to do it, but hmm, that is probably the way to go. | 09:02 |
| mwhudson | there is a way to find "all revisions touching a file" | 09:03 |
| mwhudson | i forget what it is though, i guess read the log code | 09:03 |
| Leonidas | mwhudson: the point is, if I can process bzr.dev properly, I shouldn't have any problem with bzr repos in general :) | 09:03 |
| mwhudson | Leonidas: ah :) | 09:03 |
| * Leonidas checks the cmd_log | 09:04 | |
| mwhudson | grunk, i always forget how horrible the log code is | 09:08 |
| Leonidas | show_log(bzrdev, lf, specific_fileid='TREE_ROOT') doesn't show anything. *sigh* | 09:14 |
| mwhudson | yeah, there seem to be inconsistencies around | 09:15 |
| Leonidas | that wouldn't be a big problem, if my stack would be correct, but somehow I only get one frame in pdb. | 09:17 |
| mwhudson | yay generators! | 09:18 |
| LarstiQ | Leonidas: there is tree.set_root_id() | 10:41 |
| LarstiQ | Leonidas: I'm not entirely sure what you're asking about | 10:42 |
| LarstiQ | Leonidas: and things like bzrlib.transform.adjust_root_path | 10:43 |
| LarstiQ | Leonidas: take care with the transform code though | 10:43 |
| === Daviey_ is now known as Daviey | ||
| === beaumonta is now known as abeaumont | ||
| clemente | The preferred way to convert from git to bzr is still fastimport, isn't it? | 11:36 |
| Odd_Bloke | clemente: I believe so, yes. | 11:49 |
| Odd_Bloke | bzr-git might work, but I don't know. | 11:49 |
| Pieter | or git-bzr, but that just uses fastimport | 11:52 |
| clemente | ok. Apparently development for bzr-fastimport is stuck since 2 months :-( | 11:57 |
| Odd_Bloke | clemente: Why's that a problem? It works. | 12:03 |
| clemente | Not for me; I have bug 238365 | 12:04 |
| ubottu | Launchpad bug 238365 in bzr-fastimport "Symbolic links to files with names in UTF-8 (Unicode)" [Undecided,New] https://launchpad.net/bugs/238365 | 12:04 |
| clemente | I'd like to fix it but I don't know where to start | 12:04 |
| Pieter | ie.symlink_target = data.encode('utf8') | 12:06 |
| Pieter | just change that to ie.symlink_target = data | 12:06 |
| Pieter | or so | 12:06 |
| clemente | Then all data will be stored in binary, even if it contains ¬utf-8 or even invalid utf-8 sequences | 12:09 |
| clemente | I don't know if that is allowed in bzr; but I think that git allows git | 12:09 |
| clemente | *it :-) | 12:09 |
| Pieter | a symlink is a symlink, it doesn't have any encoding specified.. I don't know why you'd try to convert it to utf-8 anyway | 12:10 |
| clemente | Why does data.encode('utf8') fail if data is aleardy utf8? Is it trying to a double conversion? | 12:14 |
| LarstiQ | without looking at the code, I'd say that is because it's data supplied from the user environment | 12:14 |
| * LarstiQ looks at the code | 12:14 | |
| clemente | Mmm... if fastimport leaves the data as it is, then bazaar complains later: | 12:19 |
| clemente | File "/w/bzr/bzr.dev-oficial/bzrlib/dirstate.py", line 1862, in _inv_entry_to_details | 12:19 |
| clemente | UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 1: ordinal not in range(128) | 12:19 |
| === beaumonta is now known as abeaumont | ||
| clemente | And the problem is really in Bazaar: bzrlib/dirstate.py, 1860: | 12:28 |
| clemente | elif kind == 'symlink': | 12:28 |
| clemente | # We don't support non-ascii targets for symlinks yet. | 12:28 |
| clemente | fingerprint = str(inv_entry.symlink_target or '') | 12:28 |
| clemente | I will report a new bug on that and link the old similar ones to it | 12:33 |
| clemente | bug 272444 | 12:44 |
| ubottu | Launchpad bug 272444 in bzr "Support symlinks to non-ascii file names" [Undecided,New] https://launchpad.net/bugs/272444 | 12:44 |
| clemente | Pieter: bzr refuses to store just any string in the original character encoding, and tries to convert everything to Unicode instead | 12:47 |
| clemente | From bug 59968: „ This root cause of this problem is that we store this data in XML, and XML1.0 doesn't permit most ASCII control codes. “ | 12:48 |
| ubottu | Launchpad bug 59968 in bzr "add should refuse bad filenames" [Medium,Confirmed] https://launchpad.net/bugs/59968 | 12:48 |
| clemente | So ie.symlink_target = data would be wrong and ie.symlink_target = data.encode('utf8') better | 12:48 |
| Pieter | messing up filenames just because your backend doesn't support the real data sounds wrong | 12:48 |
| clemente | There are lots of Unicode bugs in Bazaar... | 13:01 |
| clemente | LarstiQ: you said that it did data.encode('utf8') because it comes from the user. Would it be better to „convert it to utf8 only if it is not already utf8“? | 13:07 |
| LarstiQ | clemente: eh no, you can only encode unicode, encoding an already encoded string doesn't make sense | 13:08 |
| clemente | Or „try to convert it to utf8, but if it fails with an exception, leave the data intact“ | 13:08 |
| Pieter | clemente: that last part already happens somewhere else in fast-import | 13:08 |
| LarstiQ | clemente: so if it's utf8, and then you try to encode utf8, something is wrong | 13:09 |
| LarstiQ | Pieter: it's not messing up filenames, it's being able to reproduce them | 13:09 |
| LarstiQ | which, without extra provisions, clashes with being able to store arbitrary binary streams | 13:10 |
| Pieter | can't you just base64 them? | 13:10 |
| clemente | LarstiQ: so a try+catch around that conversion would be needed to prevent the wrong conversion | 13:10 |
| clemente | try+expect actually | 13:11 |
| clemente | except ! | 13:12 |
| LarstiQ | Pieter: that's not the point, Linux treats its filesystem paths as binary data, others don't | 13:12 |
| LarstiQ | Pieter: so you need to know what encoding a filename is in, or you are not able to check it out everywhere | 13:12 |
| LarstiQ | clemente: no | 13:12 |
| LarstiQ | clemente: in general, the entire pipeline should be: data from environment -> decode into unicode, live in unicode in the entire system -> encode on the way out | 13:13 |
| LarstiQ | clemente: there should be no mixing of encoded and unencoded data within | 13:13 |
| LarstiQ | Pieter: now, some people don't care that you can't check it out, they just want to store a binary stream and tough luck if it fais somewhere else | 13:14 |
| LarstiQ | Pieter: that should be possible | 13:14 |
| Pieter | yeah.. that seems the right way to go | 13:14 |
| LarstiQ | well | 13:15 |
| LarstiQ | it gives rise to working trees that only work in certain corner cases, which is a bad thing | 13:15 |
| LarstiQ | Pieter: the root cause here being that the common denominator doesn't allow that | 13:15 |
| clemente | But both modes are incompatible | 13:16 |
| LarstiQ | clemente: bug 59968 shouldn't be relevant anymore | 13:17 |
| ubottu | Launchpad bug 59968 in bzr "add should refuse bad filenames" [Medium,Confirmed] https://launchpad.net/bugs/59968 | 13:17 |
| LarstiQ | clemente: at least the xml part | 13:17 |
| === jelmer is now known as Guest25912 | ||
| LarstiQ | hi Guest25912 | 13:18 |
| LarstiQ | clemente: so just fix 272444 | 13:18 |
| clemente | LarstiQ: How? I think two modes are needed, configurable by the user. Some people would like „don't change my encoding, leave the data as it is even if it later fails somewhere else“ and others „please make that my data is available everywhere without encoding problems“ | 13:20 |
| LarstiQ | clemente: your use case of tres should work perfectly fine with the latter, we _know_ the encoding | 13:22 |
| LarstiQ | clemente: if we know the encoding, there is no problem | 13:22 |
| LarstiQ | clemente: the problem arises when we do not know the encoding of binary data | 13:22 |
| clemente | So the problem is not knowing the encoding used to store the target of a symlink | 13:24 |
| LarstiQ | clemente: that's a problem, not your problem. If you look at the git-fastexport output you'll see it declares the data to be utf8 encoded | 13:25 |
| Pieter | LarstiQ: only the commit messages afaik | 13:26 |
| LarstiQ | link to a file with a name in utf-8 | 13:26 |
| LarstiQ | Pieter: ^^ that's in 'expo' | 13:27 |
| Pieter | It is recommended that <path> always be encoded using UTF-8. | 13:27 |
| Pieter | that's in the manpage | 13:27 |
| LarstiQ | Pieter: right, I just looked at the output of clemente's series of git commands | 13:27 |
| LarstiQ | clemente: if you try without the symlink, it works fine, right? | 13:28 |
| clemente | LarstiQ: I think so | 13:29 |
| * LarstiQ commented out the git add prova, and that works | 13:30 | |
| LarstiQ | clemente: so the concrete problem bzr problem we're dealing with is an (now) arbitrary limitation on symlink targets | 13:31 |
| LarstiQ | hmm, maybe not | 13:31 |
| LarstiQ | clemente: if I add the symlink and commit it in bzr, it works. Branching that branch however does not. | 13:32 |
| Pieter | LarstiQ: that path is only utf-8 in the git output because it was stored as utf-8 | 13:32 |
| LarstiQ | clemente: so some parts allow it, others don't. | 13:32 |
| LarstiQ | Pieter: right, and I'd like to solve clemente's specific problem without tackling the larger issue | 13:33 |
| LarstiQ | that is a wee bit more work | 13:33 |
| Pieter | LarstiQ: by assuming it's utf-8? | 13:33 |
| LarstiQ | Pieter: by being told it is utf-8 | 13:33 |
| LarstiQ | Pieter: which is true in clemente's case | 13:34 |
| clemente | So the problem is in branch, not in add,rm,log,... A simpler testcase is: mkdir br1; cd br1; bzr init .; touch més; ln -s més prova; bzr add prova; bzr commit -m "link to utf-8 file name"; cd ..; bzr branch br1 br2 | 13:41 |
| LarstiQ | clemente: right | 13:43 |
| LarstiQ | clemente: can you write a testcase for that? | 13:43 |
| LarstiQ | a bzrlib/tests/ testcase that is | 13:43 |
| clemente | LarstiQ: I'll try that in a while, yes (first I'll need to make them run) | 13:46 |
| LarstiQ | clemente: ./bzr selftest <pattern> | 13:46 |
| clemente | ok, that was easy :-) (Although there was no documentation on bzrlib/tests/ explaining how to run them) | 13:47 |
| clemente | or how to run all | 13:48 |
| clemente | ./bzr selftest | 13:49 |
| clemente | well, that was also easy... only it wasn't documented there | 13:49 |
| LarstiQ | clemente: bzr help selftest? | 13:49 |
| LarstiQ | that, or the developer documentation | 13:49 |
| clemente | Yes, but I saw lots of tests in the bzrlib/tests/ and didn't know how to run them :-) | 13:50 |
| clemente | Maybe a README or INFO helps there | 13:50 |
| clemente | bzrlib/tests/INFO, I mean | 13:50 |
| clemente | I'll work more on this later, and write or extend some tests for utf8 | 13:56 |
| LarstiQ | luks: qannotate is nice! | 14:07 |
| LarstiQ | luks: and qbrowse! | 14:13 |
| LarstiQ | Odd_Bloke: hmmm, something funny is going on when I bisect run, it seems to keep repeating going back to the tip | 14:45 |
| LarstiQ | ho hum, why was ie.get_tar_item deprecated | 16:05 |
| Guest55688 | LarstiQ, it sucks | 16:08 |
| === Guest55688 is now known as jelmer | ||
| LarstiQ | jelmer: the removal sucks, or the function sucks? | 16:09 |
| LarstiQ | jelmer: or your nick change sucks? | 16:14 |
| jelmer | LarstiQ, get_tar_item can't provide a last modification time | 16:15 |
| jelmer | LarstiQ, which caused issues exporting the same .tar.gz file for the same revision | 16:16 |
| jelmer | LarstiQ, not sure if that's the reason it was deprecated though | 16:16 |
| LarstiQ | jelmer: I don't think that's fixed now though | 16:16 |
| LarstiQ | item.mtime = now | 16:16 |
| LarstiQ | jelmer: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/44475/focus=44476 | 16:17 |
| LarstiQ | jelmer: but now it seems the exporter code suffers from duplication | 16:17 |
| jelmer | LarstiQ, that was there before too, but it means you have to pass in "now" | 16:17 |
| LarstiQ | jelmer: mkay | 16:19 |
| LarstiQ | at least I only have to fix _export_iter_entries() once | 16:21 |
| === ferrouswheel__ is now known as ferrouswheel | ||
| LarstiQ | right, back to the bzrlib/merge.py conflict | 16:50 |
| === beaumonta is now known as abeaumont | ||
| fdv | does anybody know whether (and possibly how) "shallow" checkouts / branches are supported in 1.6? I believe I heard they would be | 18:30 |
| uws | fdv: I think the name is "stacked" | 18:33 |
| LarstiQ | yup | 18:34 |
| LarstiQ | fdv: see --stacked on branch and push for instance | 18:35 |
| fdv | right | 18:38 |
| fdv | but it depends on the availability of it's parent branch for all operations, according to the docs | 18:38 |
| fdv | do you know if bzr-svn supports it? | 18:40 |
| fdv | heh. seems to :) | 18:41 |
| LarstiQ | fdv: should only be the case for operations which it doesn't have the revisions itself for | 18:41 |
| fdv | ah, ok | 18:41 |
| LarstiQ | fdv: iirc for bzr-svn the layering wasn't entirely right | 18:41 |
| fdv | oh | 18:41 |
| LarstiQ | but it's been a while since I asked jelmer about it | 18:41 |
| fdv | the bzr-svn faq recommends it | 18:41 |
| LarstiQ | really? Then I guess he fixed it :) | 18:42 |
| fdv | (http://samba.org/~jelmer/bzr-svn/FAQ.html#cloning-a-large-subversion-branch-is-very-slow) | 18:42 |
| fdv | now I've just got to hassle the svn guys to upgrade to 1.5, then the world will be a better place :) | 18:42 |
| LarstiQ | fdv: any idea how large of a difference upgrading to 1.5 makes? | 18:43 |
| fdv | LarstiQ: nope, just read what that faq said :) | 18:44 |
| fdv | it took a week to clone the 1.4 repo to bzr, can't be worse than that ;) | 18:44 |
| fdv | LarstiQ: if and when I figure it out I can try to remember to let you know | 18:45 |
| LarstiQ | fdv: yes please, I could go badger some of my svn admins then ;) | 18:45 |
| fdv | :) | 18:46 |
| fdv | LarstiQ: svn 1.4 is so broken that there should be ample reason in itself, afaik | 18:46 |
| fdv | merging support is paramount, imo | 18:46 |
| fdv | (*working* merge support, that is) | 18:47 |
| LarstiQ | I haven't had cause to use it on svn, I heard there is this one python script you need to accomplish it with 1.5? | 18:47 |
| fdv | with 1.4 you can use svnmerge | 18:48 |
| fdv | it's supposedly fixed in 1.5 | 18:48 |
| fdv | LarstiQ: have you tried cloning the repo from 1.4? | 18:48 |
| LarstiQ | ok | 18:48 |
| LarstiQ | fdv: with bzr? Yes, although not the entire repository, but projects within it. | 18:49 |
| fdv | right | 18:49 |
| fdv | hm. it might seem to be issues with stacked branches from svn | 20:11 |
| fdv | no matter what type of repo I init, (I tried --1.6.1-rich-root, --rich-root-pack, and --subversion), the result is the same | 20:14 |
| fdv | bzr reports that it uses RepositoryFormatKnitPack5RichRoot for stacking | 20:15 |
| fdv | (after a branch command) | 20:15 |
| fdv | then it says that SvnRepository('<svnurl>') is not compatible with KnitPackRepository('local-repo-path'), different serializers | 20:16 |
| fdv | does this sound familiar to anybody? | 20:17 |
| dlee | When I push to a bzr+ssh branch or commit when bound to it, is there yet a way to have it email people about my push or commit? The bzr+ssh branch is on a Unix (FreeBSD) system I control. | 20:20 |
| fdv | uhm. I had a slightly old version of bzr-svn, sorry about the hassle | 20:33 |
| === beaumonta is now known as abeaumont | ||
| === beaumonta is now known as abeaumont | ||
| === rick_h_ is now known as rick_h | ||
| === rick_h is now known as rick_h_ | ||
| === rick_h_ is now known as rick_h_mobile | ||
| === rick_h_mobile is now known as rick_h | ||
| === rick_h is now known as rick_h_ | ||
| alefteris | trying to push over sftp and i get "bzr: ERROR: Permission denied: "/blog": [Errno 13] Permission denied" | 23:20 |
| alefteris | what can i do to see what is wrong? | 23:20 |
| alefteris | does the directory need any special permissions? | 23:25 |
| alefteris | nevermind, solved it | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!