| jonnyde1 | james_w: I know of fast-export -- but as you already stated -- it's lossy | 00:00 |
|---|---|---|
| jonnyde1 | is it now ossible by design to implement something like replaying a series of commits without loosing anything? | 00:00 |
| jonnyde1 | sorry, I've meant: is it not posible... | 00:01 |
| AfC | james_w: the overload of : (the fact that some names work only in one context, and others only in the other seems to be the sort of thing that will drive people batty) | 00:06 |
| jonnyde1 | with other words: could anyone imagine a way to write a plugin for bazaar which would just output all revisions and associated change sets as a series of commits which could be replayed again in order to create a clone which looks like the original? | 00:09 |
| radix | jonnyde1: isn't that what "bzr branch" does? | 00:09 |
| bob2 | that sounds like it would be its' own repository format | 00:10 |
| bob2 | why not just trust bzr? bzr itself has been upgraded from the 2005 preprealpha format with no data loss (unless you count ghosts). | 00:11 |
| jonnyde1 | radix: yes, indeed it does. but bzr branch creates a branch with a specific repository format. | 00:11 |
| radix | oh, I see, you want a format-independent backup. I missed that part | 00:11 |
| jonnyde1 | radix: yes, exactly :) | 00:12 |
| james_w | jonnyde1: you could come up with a non-lossy format similar to fast-export | 00:13 |
| jonnyde1 | maybe there should be a a format-independent repository format, too. One that does not consider any optimisations regarding storage efficiency.... | 00:13 |
| jonnyde1 | james_w: that's something I would imagine... This way there would always exist a format to which you can get from every other format, and the other way round | 00:14 |
| james_w | not really possible | 00:14 |
| james_w | well, yes, you could write such a thing, but there's no way to future-proof it, and once you go to a format that stores less information you are stuck | 00:15 |
| jonnyde1 | ok, that's a good point | 00:16 |
| jonnyde1 | but I think one should maybe not see it as another repository format, but just as a series of commits that could be replayed by hand, too | 00:17 |
| jonnyde1 | the only difference is | 00:17 |
| jonnyde1 | that I would have to be able to commit change sets created by someone else | 00:18 |
| jonnyde1 | I mean using his signature/checksum | 00:18 |
| jonnyde1 | (and original content of course) | 00:20 |
| lifeless | jonnydee: I think you misunderstand what repository formats do | 00:23 |
| jonnyde1 | lifeless: probably you are right... | 00:24 |
| lifeless | jonnyde1: there are two different dimensions in formats | 00:24 |
| lifeless | jonnyde1: one is _model_, one is just how things are indexed etc | 00:24 |
| lifeless | the latter is things like knits -> packs -> btree etc | 00:25 |
| lifeless | the former is things like 'plain', 'subtree', 'richroot' | 00:25 |
| lifeless | its not possible to predict the future | 00:25 |
| lifeless | so its not possible to define a model which is accurate in the future | 00:25 |
| jonnyde1 | It is just that for me it looks like so: when I commit something to a repository with format A I do provide the same information as when I commit the same content to a repository with format B | 00:26 |
| lifeless | well, when they have the same _model_ that is true | 00:26 |
| lifeless | but its not true when you commit to a format with different models | 00:26 |
| jonnyde1 | but the information I provide during commit is always the same, isn't it? | 00:27 |
| lifeless | no | 00:27 |
| jonnyde1 | I provide my content and a message | 00:27 |
| jonnyde1 | what else? | 00:27 |
| lifeless | the data on disk :) | 00:27 |
| lifeless | the entire working tree is information | 00:27 |
| lifeless | the unique id for files | 00:28 |
| lifeless | whether there are nested trees | 00:28 |
| lifeless | the UUID the commit is to be assigned | 00:28 |
| jonnyde1 | but imagine a batch script in which I create a repository | 00:29 |
| lifeless | as james_w says, you can export to e.g. fastimport, or even to a series of patches, and in terms of your user data what you get back after importing again will look the same | 00:29 |
| lifeless | but bzr will consider them to be different projects | 00:29 |
| jonnyde1 | then I do create some files, create dirs, add them, rename them, etc. | 00:29 |
| lifeless | jonnyde1: sure, we do this thousands of times in the test suite for bzr | 00:29 |
| jonnyde1 | now when I execute the same script on a repository with a different format, it just works | 00:29 |
| lifeless | jonnyde1: and every single time they are unique | 00:29 |
| jonnyde1 | ok, now I see | 00:29 |
| lifeless | jonnyde1: the script works, the identity of the content is different | 00:29 |
| jonnyde1 | so you would also get different revision ids? | 00:30 |
| lifeless | yes | 00:30 |
| lifeless | and different file ids | 00:30 |
| jonnyde1 | and how do you implement upgrade/downgrade without stumbleing over the same issues? | 00:31 |
| lifeless | we're working with the structured data | 00:31 |
| lifeless | actually, there is a logical argument here: | 00:32 |
| lifeless | if you define something that stores the very minimal data needed to exactly reproduce a bzr repo | 00:32 |
| lifeless | you have defined a bzr repository format | 00:32 |
| lifeless | its no more neutral than the formats we ship in bzr itself | 00:33 |
| jonnyde1 | makes sense... | 00:33 |
| lifeless | you might not call it a format, and you might not use bzr's format machinery to manage it, but it would be performing the same job | 00:33 |
| lifeless | if it looks like a duck, smells like a duck, and quacks like a duck, might as well call it a duck | 00:33 |
| jonnyde1 | and why doesn't svn have to deal with this issues? is it because there are no cryptographic ids? | 00:35 |
| lifeless | svn has the same issue | 00:35 |
| lifeless | if you run svn 1.5 on a svn 1.4 tree, it upgrades it and svn 1.4 will no longer work | 00:36 |
| lifeless | you have to dump and restore svn repositories to upgrade them on the back end as well | 00:36 |
| lifeless | I don't know why svn is not _percieved_ to have the same issues, but it has them :) | 00:36 |
| jonnyde1 | but I can dump the contents of 1.4 and import them into 1.5 -- and vice versa | 00:37 |
| jonnyde1 | without loss of information ... AFAIK | 00:37 |
| lifeless | you can downgrade a bzr repository from packs-0.92 to knits without loss of information | 00:37 |
| lifeless | because thats simple layout, not data model | 00:37 |
| lifeless | you can't do a merge in svn 1.4 and have it be tracked, you need svn 1.5 - thats data model | 00:38 |
| jonnyde1 | ok, I think I am starting to understand.... | 00:38 |
| jonnyde1 | well, the reason why I wish there was some kind of independent format is that I pushed a branch to launchpad using bzr.dev and its newest repository format. And after that there was no way back for downgrading.... | 00:40 |
| lifeless | jonnyde1: sure there is | 00:40 |
| lifeless | jonnyde1: bzr upgrade sftp://.... --format=FORMATNAME | 00:41 |
| lifeless | some format choices are one-way, because there is data loss going backwards | 00:41 |
| jonnyde1 | it told me something like downgrading from that format is not implemented yet... | 00:41 |
| lifeless | but the default is not like that, you would have to have explicitly chosen a format that is past that one-way barrier | 00:41 |
| lifeless | jonnyde1: whats the branch url? | 00:42 |
| jonnyde1 | yes, now I understand why. It's indeed a by design issue | 00:42 |
| jonnyde1 | well I removed the branch completely and created a new branch with an older format | 00:42 |
| lifeless | jonnyde1: what was the format you had used? | 00:43 |
| jonnyde1 | and locally I threw away my history and created a new branch with new revisions from scratch | 00:43 |
| jonnyde1 | I used --rich-root-pack, I think. But just a moment... | 00:43 |
| lifeless | jonnyde1: ok, *why* did you do that? | 00:44 |
| lifeless | jonnyde1: its not the default for a reason :) | 00:44 |
| jonnyde1 | well, I thought it sounds like it stores more information so my guess was that I should be more stable for future format changes... | 00:45 |
| lifeless | jonnyde1: you should only use defaults unless you have a specific reason to use something different | 00:45 |
| lifeless | it does store more information, and most things should work with it, but you do need a slightly newer bzr than you do for the default format, which only needs bzr 0.92 | 00:46 |
| jonnyde1 | well, that sounds reasonable. But on the other hand there isn't any suggestion to do so in the documentation or bzr help | 00:46 |
| lifeless | bzr help formats: | 00:47 |
| lifeless | ... | 00:47 |
| lifeless | rich-root-pack: | 00:47 |
| lifeless | (native) New in 1.0: Pack-based format with data compatible with | 00:47 |
| lifeless | rich-root format repositories. Incompatible with bzr < 1.0 | 00:47 |
| jonnyde1 | well, but I am always using the newest bzr version | 00:48 |
| lifeless | jonnyde1: then why did you dislike the behaviour of rich-root-pack? did something go wrong? | 00:48 |
| jonnyde1 | the problem was I upgraded my local repository to the newest rich-root-pack format | 00:49 |
| jonnyde1 | then I had to do the same with the one hosted on launchpad | 00:49 |
| lifeless | yes | 00:49 |
| jonnyde1 | because bazaar told me the formats were incompatible | 00:50 |
| lifeless | thats normal for rich-root changes, what went wrong though? | 00:50 |
| jonnyde1 | launchpad was not comfortable with a repository format named 1.7dev and rich-root-pack | 00:50 |
| lifeless | lp handles rich-root-pack fine | 00:51 |
| jonnyde1 | so actually nothing went wrong except that launchpad had a problem with it | 00:51 |
| lifeless | lp won't handle development formats, because it runs bzr releases | 00:51 |
| jonnyde1 | but it told me that 1.7 is not supported | 00:51 |
| lifeless | bzr has not released 1.7 yet | 00:51 |
| lifeless | lp only supports released bzr versions | 00:52 |
| jonnyde1 | yes, exactly. so I tried to downgrade it again | 00:52 |
| jonnyde1 | and this is where I got stucked | 00:52 |
| lifeless | if you downgrade to rich-root-packs it would have worked | 00:52 |
| lifeless | ok, for future reference - launchpad supports bzr released versions only | 00:52 |
| lifeless | you can upgrade between any format version that has the same data model | 00:53 |
| jonnyde1 | yes, maybe. but a first downgrade with wrong parameters exited with a downgrade not implemented yet. so there was left a backup.bzr at launchpad | 00:53 |
| lifeless | so *-rich-root are all compatible with each others | 00:53 |
| lifeless | you can delete backup.bzr there using hitchhiker | 00:53 |
| jonnyde1 | and the second try exited with the message that there is already a backup.bzr | 00:53 |
| lifeless | its a bug in lp that thats not easily removable | 00:53 |
| lifeless | I'm sorry you had trouble | 00:53 |
| jonnyde1 | lifeless: no problem -- really!!! :) | 00:54 |
| lifeless | and more sorry you didn't get good support :( | 00:54 |
| jonnyde1 | I mean I lost some revisions from history but there were only a few until now, anyway | 00:54 |
| jonnyde1 | it was a fresh project | 00:54 |
| jonnyde1 | And it was my fault to use a development version of bazaar | 00:55 |
| jonnyde1 | So please don't mind ;) | 00:55 |
| lifeless | ok :) | 00:55 |
| lifeless | anyhow - take away message is that you can use development formats locally, but you need to do a little special thing when pushing from them to launchpad | 00:56 |
| jonnyde1 | and regarding support: I couldn't get better support :) | 00:56 |
| lifeless | what you need to do is do 'bzr init --MODEL lp:..' rather than just a 'push' | 00:56 |
| lifeless | e.g. if you chose --development-rich-root locally, you would do 'bzr init --rich-root-pack lp:foo' to make a branch that LP understands that you can push to. | 00:57 |
| jonnyde1 | ok, thanks -- I will do that, instead | 00:57 |
| jonnyde1 | lifeless: thank you very much for taking the time to answer my questions. It is really really nice of you :) :) :) | 00:59 |
| lifeless | my pleasure | 00:59 |
| jonnyde1 | So have fun and a nice day/night . best regards | 01:00 |
| lifeless | thanks, I shall! | 01:00 |
| lifeless | jml: lol @ forcing you to use a dictionary :) | 01:23 |
| sohail | hey guys | 01:24 |
| sohail | I've been working on a project and I want to put up a repo of it (don't really care about history). Is there some document that tells me how to set up my development so I can push to that repo securely? | 01:25 |
| lifeless | bzr push URL ? :) | 01:26 |
| sohail | over http? | 01:26 |
| sohail | sorry my brain is fried today but I fear this is as good as it is going to get! | 01:27 |
| lifeless | sure, if you have bzr configured in your apache config and use https rather than http | 01:27 |
| lifeless | or you can use sftp or bzr+ssh | 01:27 |
| sohail | ah | 01:27 |
| sohail | so I hate mucking around with apache... Can I do it without telling Apache this is bzr? | 01:28 |
| lifeless | is you isntall the webdav plugin and enable webdav on your server (and use https :)) | 01:29 |
| lifeless | most people use bzr+ssh or sftp though | 01:29 |
| sohail | so how do I let people clone it then? | 01:29 |
| sohail | like I don't care about pushing over ssh, that's what I do now | 01:29 |
| sohail | but I don't know how to let people clone it | 01:30 |
| sohail | again, please refer to brain fried state above if this sounds totally stupid | 01:30 |
| lifeless | just have the place you pushed to be served by apache | 01:31 |
| sohail | over plain http? | 01:31 |
| sohail | sweet | 01:31 |
| sohail | no futzing around with apache? | 01:31 |
| sohail | double sweet | 01:31 |
| sohail | so do you guys have one bzr repository for all your projects or multiple repos | 01:35 |
| mwhudson | multiple repos, on the whole | 01:35 |
| sohail | I see | 01:36 |
| sohail | what are the benefits? | 01:36 |
| sohail | mwhudson, I'm not a bzr expert but what do you do when one of your projects depends on another? | 01:39 |
| mwhudson | sohail: symlinks, basically | 01:40 |
| mwhudson | but i'm not really responsible for the setup or deployment side of things | 01:40 |
| sohail | you non-windows user you | 01:41 |
| mwhudson | :) | 01:41 |
| mwhudson | there's no real disadvantage to one-big-repo, i think | 01:41 |
| sohail | symlinks are a perfect solution until you hit the dreaded C:\> prompt | 01:41 |
| lifeless | sohail: when there are dependencies between projects, I think best practice is to install the inner one and build on the installed copy | 01:43 |
| lifeless | and/or provide variables to build on an uninstalled copy | 01:43 |
| sohail | mebbe | 01:44 |
| sohail | not a huge deal anyway | 01:44 |
| sohail | now next question :-D | 01:44 |
| sohail | how can I track a svn repository in bzr? | 01:44 |
| mwhudson | various ways | 01:45 |
| mwhudson | request an import on launchpad | 01:45 |
| mwhudson | or bzr-svn | 01:45 |
| mwhudson | being the two main ways | 01:45 |
| sohail | bzr-svn sounds promising | 01:45 |
| === andreas__ is now known as ahasenack | ||
| kiko | let's say | 02:08 |
| kiko | I have a file in one branch that has its own history | 02:08 |
| kiko | how do I bring that file into another branch with full history? | 02:08 |
| lifeless | file histories don't have log messages, you need the full branche for that | 02:08 |
| lifeless | so you'd do bzr join to join the branches | 02:08 |
| kiko | gotcha. | 02:08 |
| kiko | so | 02:46 |
| kiko | is having some big files in .bzr/repository/upload normal? | 02:46 |
| kiko | can I kill them? :-( | 02:47 |
| lifeless | they are temporary files during commit/push/pull/merge | 02:48 |
| lifeless | if you have no bzr processess doing that, then yes. | 02:48 |
| kiko | thanks | 02:48 |
| kiko | should they not be cleaned up the next push or so? | 02:48 |
| lifeless | they only get left if bzr gets disconnected/physically interrupted | 02:48 |
| kiko | well | 02:48 |
| lifeless | kiko: we can't tell if they belong to an active process, so no. | 02:49 |
| kiko | the funny thing is that this file is 300MB, but the actual .bzr folder itself is about 1MB | 02:49 |
| lifeless | probably you interrupted a bzr push of launchpad to that repo :) | 02:49 |
| kiko | could it have been a bzr merge? | 02:50 |
| lifeless | sure | 02:50 |
| kiko | ah, then that's what it was | 02:50 |
| kiko | how could you guess?! | 02:50 |
| lifeless | I know how big launchpad is :P | 02:50 |
| rocky | jelmer: don't suppose you had any luck tracking down that issue today ? | 03:06 |
| jelmer | rocky, I did | 03:27 |
| rocky | oh? something i can test? | 03:27 |
| jelmer | It should work now, haven't tried with your URL though | 03:27 |
| jelmer | rocky, 0.4 branch | 03:27 |
| * rocky tries | 03:27 | |
| rocky | jelmer: while i'm waiting for this to checkout ... do you use tracbzr much? | 03:29 |
| Peng_ | Why have bzr-svn default to 1.6-rich-root? | 03:30 |
| jelmer | rocky, yeah, we use it for bitlbee and ctrlproxy | 03:30 |
| jelmer | Peng_, Seemed like a sane choice since it'll only work with bzr 1.6 anyway | 03:30 |
| rocky | jelmer: oh, should i be creating my repo with --rich-root-pack or 1.6-rich-root ? | 03:30 |
| jelmer | rocky, either will work | 03:30 |
| rocky | jelmer: another error --> http://cluebin.appspot.com/pasted/801 | 03:31 |
| Peng_ | rocky: 1.6-rich-root supports stacking, but isn't compatible with older versions of bzr. | 03:31 |
| jelmer | rocky, sorry, uncommitted change | 03:32 |
| rocky | jelmer: let me know when your'e ready | 03:33 |
| jelmer | rocky, please try again | 03:33 |
| rocky | jelmer: k, recreated repo and checking out the svn source again | 03:34 |
| rocky | jelmer: well, the checkout is taking a lot longer this time ;) | 03:37 |
| rocky | the amount of http requests this is doing for a checkout is astounding | 03:41 |
| * rocky is watching his remote server logs | 03:41 | |
| rocky | jelmer: when i'm doing a checkout of a particular folder/trunk ... why is it querying all kinds of other folders that aren't in the hiearchy ? | 03:42 |
| jelmer | rocky: it needs to search for revisions not on the mainline | 03:43 |
| rocky | jelmer: ok it worked ... and i just added a dummy test file and it's considerably faster, but still slower than i'd expect ... that commit (of one file) did about 50 http requests to my server | 03:44 |
| jelmer | rocky, incremental commits should be faster | 03:44 |
| rocky | define: incremental commit | 03:44 |
| jelmer | rocky, if you do another commit, it should be faster | 03:45 |
| jelmer | if not, how fast is it? | 03:45 |
| rocky | even when i do a commit it's checking all kinds of branches of other projects that aren't in my project's hierarchy | 03:46 |
| rocky | this 2nd commit is taking longer than the first one did | 03:46 |
| jelmer | rocky, It has to check whether the revision is already present elsewhere | 03:47 |
| jelmer | rocky, since bzr does a push under the hood | 03:47 |
| rocky | jelmer: added a 2nd file... | 03:49 |
| rocky | time bzr commit -m "Another checkin test" | 03:49 |
| rocky | Committing to: https://dev.serverzen.com/svn/cluemapper/ClueMapper/trunk | 03:49 |
| rocky | added test.txt | 03:49 |
| rocky | Committed revision 113. | 03:49 |
| rocky | real1m4.238s | 03:49 |
| rocky | user0m2.168s | 03:49 |
| rocky | sys0m0.148s | 03:49 |
| rocky | (bzr-1.6)rocky@zebrax:/usr/misc/apps/bzr-1.6/sandbox/repo/ClueMapper-trunk$ | 03:49 |
| rocky | whoops, sorry | 03:49 |
| rocky | didn't realize it was so much | 03:49 |
| jelmer | rocky: This is bug 158657 | 03:50 |
| ubottu | Launchpad bug 158657 in bzr-svn "ability to limit paths searched by lookup_revision_id()" [Medium,Triaged] https://launchpad.net/bugs/158657 | 03:50 |
| rocky | jelmer: that commit that i just pasted ... did 347 svn requests according to my remote apache log | 03:51 |
| rocky | so that's my 3rd commit ... so far it seems like things are slowing down more | 03:52 |
| * rocky wonders if he's the only one having these major slowdown issues | 03:54 | |
| Peng_ | You're not | 03:58 |
| jelmer | rocky, do you have a lot of directories on the same level as your branch? | 04:01 |
| rocky | jelmer: https://dev.serverzen.com/svn/cluemapper/ClueMapper/trunk/ is the "branch" i'm "bzr checking out" ... you can look at it your self... at the same "level" as trunk the only other folders are branches and tags in true svn style | 04:04 |
| jelmer | rocky, there's a lot of things at the same level it looks like | 04:05 |
| jelmer | it'll check https://dev.serverzen.com/svn/*/* | 04:05 |
| rocky | jelmer: lol how's that the same level? | 04:05 |
| jelmer | same level of nesting in the repository | 04:06 |
| mwhudson | jelmer: shouldn't you be asleep? :) | 04:09 |
| rocky | jelmer: hmm.... so where does this leave us? :) | 04:10 |
| jelmer | mwhudson, yes, I *should* :-) messed up biorhythm again | 04:10 |
| jelmer | rocky, it'll be slow for a while, until bug 158657 is fixed | 04:10 |
| ubottu | Launchpad bug 158657 in bzr-svn "ability to limit paths searched by lookup_revision_id()" [Medium,Triaged] https://launchpad.net/bugs/158657 | 04:10 |
| rocky | jelmer: i honestly don't think i'll be able to stick it out much longer... these slow commits have been killing me now for the past several weeks :/ | 04:11 |
| jelmer | rocky, alternatively, you can just work in bzr and push to svn in batches | 04:11 |
| rocky | jelmer: the only reason i haven't switched a lot of my stuff to bzr is the fact that i want to reduce the barrier for people to help in my community projects | 04:12 |
| mwhudson | i took that line for a while | 04:13 |
| mwhudson | then i just gave up and switched 100% to bzr | 04:13 |
| jelmer | rocky, what I mean is, you don't have to use a checkout | 04:14 |
| jelmer | rocky, you can just use bzr and maintain a mirror in svn using bzr-svn | 04:14 |
| lifeless | abentley: welcome back :) | 05:51 |
| abentley | lifeless: thanks. | 05:52 |
| mwhudson | heh, wb bb | 06:22 |
| * vila warms up, reset clock, 22min to go to start at 08/08/22 08:00 | 06:39 | |
| lifeless | vila: :) | 06:49 |
| * vila 's internal security check failed, caffeine too low. launching delayed by ~8mins | 06:58 | |
| lifeless | rotfl | 06:59 |
| lifeless | jam: isn't it your bedtime ? :) | 07:01 |
| vila | 08/08/22 08:08:22 IGNITION | 07:08 |
| vila | Hello World ! | 07:08 |
| lifeless | welcome :) | 07:10 |
| vila | lifeless: thanks :) | 07:11 |
| mwhudson | vila: hi :) | 07:14 |
| vila | mwhudson: hi ! | 07:17 |
| uws | Is there a way to "svn checkout" using bzr without downloading full history? | 08:59 |
| uws | Just a "get me started RIGHT NOW" basically? | 08:59 |
| uws | only downloading history when needed, e.g. for diffing | 08:59 |
| uws | or just the last few revisions | 09:00 |
| RAOF | uws: I belive the answer is 'yes'; bzr checkout --lightweight will get you a 'this revision only' checkout, I believe. | 09:01 |
| uws | hmmm. will that work for foreign svn branches as well? | 09:01 |
| luks | probably, but it will still need to cache all the revision metadata | 09:01 |
| luks | but I probably shouldn't be saying this if I'm not sure :) | 09:02 |
| uws | it would be a killer feature for many ppl forced to use svn today | 09:02 |
| uws | importing like ~10000 revisions into bzr is NOT fun | 09:03 |
| uws | can take > 2 days | 09:03 |
| mwhudson | stacked branches may give you that | 09:03 |
| mwhudson | at some point | 09:03 |
| vigneswari | hello all | 09:23 |
| vigneswari | how to set permission to access particular folder alone for a particular user | 09:23 |
| bob2 | bzr doesn't support that, sorry | 09:23 |
| bob2 | except by making it its own branch | 09:24 |
| vigneswari | bob2, who will make that? users they themselves | 09:25 |
| vigneswari | but svn has this feature know? | 09:25 |
| bob2 | sorry, I don't understand the first part of your question | 09:26 |
| bob2 | but I believe svn lets you set permissions on particular paths in a repository | 09:26 |
| vigneswari | bob2, yes.. | 09:26 |
| vigneswari | making it its own branch? | 09:27 |
| lifeless | uws: 'bzr branch --stacked' I believe, should work now | 09:27 |
| vigneswari | means...user will create the branch as own branch? | 09:27 |
| bob2 | you can restrict access to branches, just not to particular dirs within them | 09:28 |
| vigneswari | bob2, ok how to do that | 09:29 |
| bob2 | just create the branch and set the unix permissions on it so only they can access it | 09:29 |
| bob2 | assuming you're on unix | 09:29 |
| uws | lifeless: this stacked branch will cache locally? | 09:39 |
| uws | lifeless: and can I convert it to a real branch, e.g. overnight when I'm not using it? | 09:39 |
| lifeless | uws: you can just branch from it again to make it full | 09:41 |
| lifeless | uws: work you do locally will be stored locally, if you pull from somewhere etc it will store it locally if its not in the parent already | 09:42 |
| uws | lifeless: so it's basically a "smart" branch that only pulls when really needed. | 09:43 |
| uws | so that I can start hackign right away | 09:43 |
| uws | use case: work on $project which is hosted in svn, it has like 1000 revisions | 09:43 |
| lifeless | yes, and one that needs to be connected to the real server - because it doesn't have everything locally | 09:43 |
| uws | and I don't want to touch svn ;) | 09:43 |
| uws | and I do want to get started right away | 09:44 |
| lifeless | uws: yes, thats the use case for it - avoid downloading deep history | 09:44 |
| uws | lifeless: will "bzr log" require all history? | 09:45 |
| lifeless | uws: naturally | 09:45 |
| lifeless | uws: unless you do --line or whatever, it will do it incrementally as normal | 09:45 |
| uws | lifeless: (I thought perhaps commit log messages are stored separately from the actual diffs) | 09:46 |
| uws | anyway, this is 1.6 only right? | 09:46 |
| lifeless | right | 09:46 |
| lifeless | uws: it will access just the commit messages from the remote server | 09:46 |
| uws | Can I define my own prefixes, just like lp: ? | 10:59 |
| luks | only using a plugin | 11:00 |
| luks | but you might want https://launchpad.net/bzr-bookmarks instead? | 11:00 |
| luks | it allows you to define aliase and then bm:<alias> | 11:01 |
| luks | or bm:<alias>/some/other/subpath | 11:01 |
| luks | this plugin was originally written only as a joke, and turned to be probably the most useful plugin I wrote :) | 11:02 |
| bob2 | haha | 11:02 |
| siretart | any recommendations how to install bzr on a sles9 system? | 11:04 |
| luks | download the tarball and python setup.py install? | 11:04 |
| luks | (I expect the packaged version to be ancient) | 11:05 |
| siretart | sles features python 2.3 | 11:06 |
| siretart | so I'd first have to deploy python2.5 first.. that's why I ask if someone had already done that | 11:07 |
| luks | oh | 11:08 |
| bob2 | bzr py2exe installer + wine | 11:08 |
| uws | luks: trying your bm plugin now. can I use for prefixes as well? | 11:13 |
| luks | uws: not for lp: like prefixes | 11:14 |
| luks | uws: but you can use bm:<alias>/some/other/path instead of yourprefix:some/other/path | 11:14 |
| uws | luks: Thanks, got it to work! | 11:16 |
| uws | bzr log bm:ilps/PROJECT/BRANCH works ;) | 11:17 |
| uws | (ilps is my university department/group) | 11:17 |
| lifeless | siretart: 2.4 is all we need | 11:35 |
| lifeless | siretart: can you get python 2.4 for sles9? | 11:35 |
| siretart | lifeless: sles9 only ships python2.3. I have now installed python2.5 in a private, user writable path | 12:05 |
| siretart | now I have a working bzr 1.6rc5 :-) - now let's get this cvsps thing working | 12:05 |
| siretart | I assume that version 1.99-152.1 is stone age, right? | 12:06 |
| lifeless | no idea :) | 12:07 |
| lifeless | <- Ubuntu/Debian only :P | 12:07 |
| siretart | isn't there a cvsps branch on launchpad somewhere? | 12:29 |
| siretart | does cvsps upstream still exist at all? | 12:29 |
| lifeless | gnight | 12:38 |
| lifeless | siretart: I don't know, I would tend to apt-get source :P | 12:38 |
| siretart | yeah | 12:40 |
| siretart | okay, cvsps_import seems to be running now on this sles9 system. converting a 10 yrs old cvs managed perl project to bzr for good | 12:47 |
| * kiko reminds siretart of his debts to society :-P | 12:54 | |
| fullermd | Surely 10 years of using CVS is enough to work off any debt :-P | 12:55 |
| gour | 10 years of CVS? it sounds as eternity...i'm (was) not ready for it :-) | 12:57 |
| fullermd | Well, *I* had 10 years of CVS. "Eternity" is what goes by waiting for 'bzr branch' across a network. 10 years of CVS is much, much worse... | 12:57 |
| mwhudson | well, i got a job working for this company who use this cutting edge version control system and ended up learning far more about cvs that i did (or wanted) to know! | 13:06 |
| siretart | kiko: hey, I also have a real job :-) | 13:07 |
| fullermd | You "win". :p | 13:07 |
| kiko | siretart, no you don't!! | 13:08 |
| * awilkins knows more about MKS that he wants to know | 13:10 | |
| awilkins | MKS is based on CVS. | 13:10 |
| awilkins | With added evil | 13:10 |
| \3TATUK | Which port does the bzr smart server use default? | 13:14 |
| hsn_ | is bzr native faster then bzr+ssh? | 13:17 |
| AfC | 4155 | 13:22 |
| Leonidas | how to do an iter_changes from revision 0 to the first one? | 13:24 |
| Leonidas | iter_changes can, as far as I know just compare between trees and I have no idea how to get the empty tree for revision zero (empty repo) | 13:25 |
| fullermd | hsn_: It's the same protocol. It's presumably marginally faster since it doesn't have to do all the ssh-layer negotiation and encryption and all, but that's probably either constant of negligable. | 13:25 |
| LeoNerd | fullermd: I use the ssh controlmaster stuff for most of my connections anyway... so setup/auth/teardown time doesn't happen | 13:30 |
| fullermd | I keep wnating to play with that, but last time I looked at it it had some giant gaping flaw that made it unworkable without going way out of my way. Don't remember what it was... | 13:35 |
| LeoNerd | It can get a bit annoying on occasions, in those rare few times you -want- a new connectin | 13:36 |
| LeoNerd | E.g. when upgrading an ssh server | 13:36 |
| hsn_ | bazaar works on python2.3? | 13:54 |
| james_w | hsn_: no, you need at least 2.4 | 13:54 |
| hsn_ | sadly we have centos 4.6 on all our servers | 13:58 |
| uws | Yay | 14:09 |
| uws | project at $work (univ) has officially switched from SVN to Bazaar! | 14:09 |
| em1 | hi | 14:14 |
| em1 | it always complain "You have not informed bzr of your launchpad login.." | 14:15 |
| em1 | what should i do? | 14:15 |
| em1 | im a newbie | 14:15 |
| luks | bzr launchpad-login USERNAME | 14:17 |
| luks | is that a problem? :) | 14:18 |
| em1 | yes | 14:27 |
| em1 | luks | 14:28 |
| em1 | yes, what i should input? | 14:28 |
| luks | didn't I say it already? | 14:28 |
| em1 | what did you say | 14:29 |
| em1 | should i input 'bzr launchpad-login em1'? | 14:30 |
| gour | em1: <luks> bzr launchpad-login USERNAME | 14:30 |
| gour | em1: have you registered at LP? | 14:30 |
| em1 | no | 14:30 |
| luks | bzr launchpad-login USERNAME | 14:30 |
| gour | then do that 1st | 14:30 |
| em1 | ok | 14:31 |
| awilkins | Someone with username em1 has been a launchpad member since 2006 though | 14:31 |
| em1 | luks, i have type 'bzr launchpad-login USERNAME' and that does not help, lol, apparenly Username should be replace with something | 14:32 |
| luks | well, with your launchpad username :) | 14:32 |
| em1 | after i registed a name, but bzr still does not satisify, how to do?, it say: | 14:43 |
| em1 | bzr: ERROR: The user jvava has not registered any SSH keys with Launchpad. | 14:43 |
| gour | em1: paste some of your ssh keys to LP | 14:43 |
| em1 | gour, i dont know where and what my ssh keys | 14:44 |
| gour | em1: do you use ssh? on LP login and then change details --> SSH keys | 14:45 |
| gour | em1: read https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair | 14:45 |
| em1 | gour, im using bzr in cmd console in window xp | 14:46 |
| gour | em1: i'm on linux, but read the above url and configure following putty setup | 14:47 |
| em1 | ok, im checking it | 14:48 |
| jelmer | beuno, any chance another upload of bzr-search can be sponsored | 14:56 |
| jelmer | the license was incorrect so the previous one was rejected | 14:56 |
| em1 | i dont know how to treat the private key while public key is pasted into the textbox | 14:56 |
| jelmer | beuno, and please say thanks to mlt for sponsoring from me | 14:57 |
| gour | em1: is your public key accepted on LP? | 14:57 |
| beuno | jelmer, I can sure try! Did you re-upload? (I will thank her) | 14:57 |
| em1 | gour, i have not download putty , can i use java produing public/private key instead? | 14:58 |
| gour | em1: cannot say for sure. no idea about windows & ssh | 14:58 |
| gour | ...applications | 14:59 |
| em1 | windows have the concept of ssh | 14:59 |
| em1 | can i use a a password to pass the identify ? | 14:59 |
| em1 | i have a password when i registerd | 14:59 |
| gour | you must have your public ssh key on LP | 14:59 |
| jelmer | beuno, yep, to mentors.debian.net | 15:00 |
| gour | em1: have you read Why you need an SSH key | 15:00 |
| LarstiQ | em1: alternatively, you can just ignore the message. | 15:01 |
| beuno | jelmer, will pass it on | 15:01 |
| em1 | i estimated that the ssh key is identical to one java produced though they all be rsa key pair | 15:01 |
| em1 | gour, i have read, but not know very much of it convey | 15:01 |
| em1 | Larstiq, i just want to checkout a branch | 15:02 |
| em1 | must i have a ssh key? | 15:02 |
| gour | "To push code branches to Launchpad you first need to generate your SSH key." | 15:02 |
| em1 | i see | 15:02 |
| LarstiQ | em1: do you want to push changes, or only get changes? | 15:02 |
| em1 | i have not need to push changes , lol | 15:03 |
| em1 | but why can not i download all? when i input 'bzr branch lp:openerp' | 15:04 |
| LarstiQ | em1: so in that case, you don't need to have a launchpad login set, and can ignore that it says you don't. | 15:04 |
| em1 | in fact, i got only two files | 15:04 |
| * LarstiQ goes fetch his bike from the repairshop | 15:05 | |
| em1 | how to check out source? is it 'bzr co lp:xx'? | 15:09 |
| gour | em1: see http://bazaar.launchpad.net/~openerp/openerp/package-script/files | 15:11 |
| pickscrape | I'm struggling to find docs on how to configure branch.conf to make bzr send more 'automatic' | 15:12 |
| pickscrape | i.e. pre-populating the destination email address etc | 15:13 |
| gour | em1: those 2 files are 'sll' | 15:13 |
| gour | *all | 15:13 |
| em1 | then where is all sources, in the office site i read that download all source by that command | 15:15 |
| gour | em1: have you executed that python script? | 15:15 |
| gour | pickscrape: bzr help configuration ? | 15:16 |
| em1 | no, i have not python engine installed until now | 15:17 |
| gour | well, install it then ;) | 15:17 |
| em1 | by running the python script can i got all sources? | 15:17 |
| gour | most probably | 15:18 |
| em1 | look, still error: 'ImportError: No module named bzrlib.builtins' | 15:25 |
| awilkins | pickscrape: It can read it from the child_submit_to parameter on the submit branches branch.conf file, I think | 15:30 |
| pickscrape | awilkins: Ah, thanks! | 15:32 |
| pickscrape | I'm seeing that in the 1.3 release notes, but google isn't finding it in any actual documentation | 15:32 |
| awilkins | pickscrape: I confess, I read the code to find out | 15:32 |
| pickscrape | :) | 15:35 |
| pickscrape | It looks like there is a hole in the documentation there. Does such a thing warrant a bug raising? | 15:35 |
| awilkins | I would say so. Or a patch to the cmd help | 15:35 |
| pickscrape | Does the cmd help also get reflected in the online documentation? | 15:36 |
| awilkins | Looks like it just scrapes them to make the user reference, but it should also go in the "branch type specific options" section of the config lists | 15:38 |
| awilkins | Gah, really need a "supress repacking" options | 15:49 |
| pickscrape | When people on the bzr mailing list review [MERGE] emails, what mail client do they generally use? (general question) | 16:15 |
| pickscrape | I'm using Thunderbird and I find that replying to such a mail doesn't give the patch part | 16:15 |
| pickscrape | I suppose I could just copy and paste it from the email, just wondering if that's what everyone else has to do too, or if I'm missing something. | 16:16 |
| LarstiQ | pickscrape: personally, mutt | 16:20 |
| LarstiQ | pickscrape: but others use Thunderbird/Evolution/mutt, etc | 16:20 |
| fullermd | Others have all sorts of weird personality quirks ;p | 16:21 |
| awilkins_ | I use Thunderbird ; it shows the attachments inline if they are text, which is why it seems weird when replying and they don't show up. | 16:21 |
| jelmer | don't forget gnus ;-) | 16:22 |
| pickscrape | awilkins_: do you just copy and paste if you reply to review code then? | 16:22 |
| awilkins_ | pickscrape: As yet, my review comments have been limited to "Looks ok to me" | 16:22 |
| pickscrape | I'm just plotting our next evolution in workflow following our migration to bzr and I want to have all bases covered :) | 16:23 |
| awilkins_ | pickscrape: But I'd probably cut-n-paste from the original mail view if I had to | 16:23 |
| pickscrape | Right. Makes sense: I think I was just surprised that it wasn't just there when hitting reply because as you say it is there in the reader display | 16:23 |
| === awilkins_ is now known as awilkins | ||
| fullermd | I'd just read in the patch, write in my comments, and delete the bits I wasn't touching on. | 16:23 |
| pickscrape | I really like the idea of being able to annotate beneath specific lines in the code. | 16:24 |
| awilkins | fullermd: You're using some kind of vim-based mailer? | 16:25 |
| LarstiQ | mutt \o/ | 16:26 |
| LarstiQ | pickscrape, awilkins: you might want to ask abentley, I believe he used Thunderbird as well | 16:26 |
| pickscrape | I keep meaning to try mutt, but Thunderbird's colorediffs extension is *really* nice. | 16:26 |
| abentley | LarstiQ, pickscrape, awilkins: Thunderbird used to include text attachments in replies. I am upset that it no longer does. I just select all, and Ctrl+Shift+v | 16:27 |
| LarstiQ | abentley: ouch, that seems like a bad decision. | 16:28 |
| awilkins | It doesn't even have an option for it, as far as I can see | 16:29 |
| luks | same for evolution, it used to include them and now it doesn't | 16:30 |
| pickscrape | Yeah, I dug around for an option but found nothing (even in the advanced config editor). | 16:30 |
| fullermd | awilkins: Well, I sure wouldn't use a mailer that didn't let me choose my own decent editor for the mail writing bit... | 16:46 |
| cody-somerville | Is there a good bzr gui client for Windows? | 16:46 |
| LarstiQ | cody-somerville: have you looked at TortoiseBZR? | 16:48 |
| cody-somerville | LarstiQ, Yes. It only does commit and diff and branch | 16:48 |
| LarstiQ | hmm, that doesn't sound like what I think it should do. | 16:48 |
| Tak | there's bzr-gtk/olive for win32... | 16:50 |
| LarstiQ | cody-somerville: other than that, I think it's Olive or bzr-eclipse (possibly bzr-visualstudio) | 16:50 |
| Verterok | cody-somerville: thre's also qbzr | 16:51 |
| LarstiQ | cody-somerville: do you spend time on win32 often? | 16:51 |
| cody-somerville | LarstiQ, Not at all | 16:51 |
| LarstiQ | Verterok: do you highlight on bzr-eclipse? :) | 16:51 |
| Verterok | LarstiQ: hi | 16:51 |
| LarstiQ | cody-somerville: Alas. We could use some more people there. | 16:51 |
| Verterok | LarstiQ: sure :) | 16:51 |
| cody-somerville | LarstiQ, Two of my coworkers from my previous employer use bzr on Windows. | 16:52 |
| Verterok | LarstiQ: and a few more hilights bzr-eclipse related ones (xmloputput, eclipse and so on) :) | 16:53 |
| Tak | I use bzr on windows, when I have to | 16:53 |
| LarstiQ | cody-somerville: would they perchance be willing to assist in development? | 16:54 |
| cody-somerville | LarstiQ, I doubt it :-] | 16:55 |
| LarstiQ | cody-somerville: darn :) | 16:55 |
| LarstiQ | Verterok: :) | 16:55 |
| cody-somerville | I'll be happy to pass along any bug reports though | 16:55 |
| LarstiQ | cody-somerville: cool | 16:56 |
| * LarstiQ proceeds to take his desk apart | 16:58 | |
| hsn_ | there is difference between bzr check output on windows and unix. On unix it prints summary while on windows not | 17:09 |
| awilkins | hsn_: It prints a summary here, what version of bzr are you using? | 17:13 |
| === toytoy_ is now known as toytoy | ||
| bob2 | check bzr alias output to make sure you don't have an alias with -q or something | 17:26 |
| === kiko is now known as kiko-fud | ||
| === vednis is now known as mars | ||
| hsn_ | awilkins: bzr 1.5 python install | 19:18 |
| hsn_ | it shows progressbar but no summary | 19:20 |
| hsn_ | bzr check -v gives same result | 19:21 |
| jam | vila: are you still around? | 19:25 |
| jam | Just wanted to say congrats on your first day | 19:25 |
| beuno | right! vila, welcome :) | 19:26 |
| beuno | jam, btw, I'm going to be sprinting next week in London, so I don't know how/when I'll be able to get to the packaging :/ | 19:27 |
| hsn_ | oh, its not printed because of installed plugin xmloutput | 19:27 |
| hsn_ | uninstalling plugin makes it work | 19:28 |
| jam | beuno: Well, if you just test out luks stuff and give the green light, it seems easy enough for me to make it work. | 19:28 |
| jam | I'd like to move the appropriate branches to ~bzr locations | 19:28 |
| jam | etc | 19:28 |
| jam | rather than have the official packaging branches be in his namespace. | 19:28 |
| jam | nothing against him, but nobody else can commit there :) | 19:28 |
| beuno | jam, I'll try and get to it, but I'm very behind on what I want to have finished, and I fly tomorrow | 19:29 |
| beuno | what you may be able to do | 19:29 |
| beuno | is trick someone into uploading them into their PPA | 19:29 |
| beuno | and you just copy each one to ~bzr | 19:29 |
| beuno | (possibly test first) | 19:30 |
| jam | beuno: bah, testing :) | 19:30 |
| fullermd | All testing ever does is cause bugs. | 19:31 |
| jam | beuno: do you have the link? | 19:33 |
| jam | I sort of remember it | 19:33 |
| jam | https://edge.launchpad.net/~luks/bzr/packaging-tools | 19:34 |
| jam | right? | 19:34 |
| beuno | jam, yeap | 19:34 |
| === mw is now known as mw|food | ||
| === kiko-fud is now known as kiko | ||
| jam | james_w: By the way "bzr co lp:bzr-builddeb" doesn't work because you have the wrong branch nominated as your 'development focus'. | 19:50 |
| === mw|food is now known as mw | ||
| hendrixski_work | :-( is there a way to branch from what you're locally working on... kind of like in git using git checkout -b "newBranchName" where it creates a branch in place? | 20:24 |
| hendrixski_work | or, would I have to go to a separate directory and branch from the original directories location using bzr? | 20:25 |
| cody-somerville | hendrixski_work, sure | 20:25 |
| cody-somerville | hendrixski_work, do you want it to branch the working tree (ie. stuff that might not be committed)? | 20:25 |
| hendrixski_work | cody-somerville: I don't know the names for doing these operations (which makes googling difficult) but from your description... yes, I've got some changes I made that I'm not sure I want to comit to my main effort, so I want to branch them, and then be able to revert to a different branch, take that in a direction ...etc. | 20:27 |
| cody-somerville | just copy the directory | 20:27 |
| hendrixski_work | basically trying to do what this guy is doing in this video using git http://www.g2one.com/quickcasts/movies/gitGrailsScreencast_web_final_compressed.mov | 20:28 |
| hendrixski_work | cody-somerville: ah, so I need to copy it elsewhere and branch against it? | 20:29 |
| cody-somerville | copying it makes a branch | 20:29 |
| cody-somerville | although if you want the second branch to see your first branch as the parent branch, you'll want to use bzr branch | 20:30 |
| cody-somerville | In which case, I think you'll have to commit your changes | 20:31 |
| cody-somerville | Or... | 20:31 |
| cody-somerville | I suppose you could just branch your current instance w/o committing | 20:32 |
| hendrixski_work | hhmm, 'cause in the git video the guy creates a branch of the current directory without switching or copying or anything... then does some changes, then reverts to a different branch, and merges ... all without switching. And.. I don't want to learn git, I'm just barely learning bzr, and i like it. | 20:32 |
| pickscrape | You can bzr branch old_branch new_branch and then in new_branch bzr merge --uncommitted ../oldbranch | 20:34 |
| pickscrape | Another alternative is to use shelve to put changes you want to deal with later away in a safe place | 20:36 |
| hendrixski_work | shelve? | 20:37 |
| pickscrape | Lets you put changes aside and pull them out again later | 20:38 |
| hendrixski_work | cool | 20:38 |
| pickscrape | If you have bzrtools installed, bzr help shelve or bzr help shelf | 20:38 |
| hendrixski_work | hhmm, well, I'll look at those options :-) | 20:40 |
| hendrixski_work | Thanks cody-somerville and pickscrape | 20:40 |
| cody-somerville | \o_ | 20:40 |
| pickscrape | np | 20:40 |
| awilkins | hendrixski_work: Watching this video, he is switching, it's just that git is doing it implicitly | 21:00 |
| awilkins | hendrixski_work: The same workflow is a little more involved with bzr because you need a repo, and to switch as quickly (with simple branch names not paths) you need to be running lightweight checkouts or have a certain patch that's pending in the PQM | 21:02 |
| hendrixski_work | oh | 21:02 |
| awilkins | Actually, you don't need a repo, it just works a lot better if you do | 21:03 |
| awilkins | And he's using rebase in at least one place | 21:04 |
| awilkins | It's a nice video, makes Grails and git look really good :) | 21:06 |
| awilkins | And it clarified what "rebase" does in my head (although not yet, why it is desirable) | 21:08 |
| awilkins | Which so far I hadn't understood | 21:08 |
| awilkins | jelmer: Since you wrote rebase for bzr, perhaps you can tell me what it's useful for :-) | 21:13 |
| jam | awilkins: responding to people who say they want to rebase because they use git and think they need it | 21:13 |
| jam | awilkins: mostly it is used to make your version history "better looking" than it really is | 21:13 |
| awilkins | Ah, political features | 21:13 |
| === jaypipes is now known as jaypipes-afk | ||
| awilkins | In both senses :-) | 21:13 |
| jam | There are a couple use cases that I've seen | 21:14 |
| awilkins | Is that the rebase -i for super-tidying | 21:14 |
| jam | 1) You submit your changes to upstream as a series of patches | 21:14 |
| jam | and for whatever reason you need that to be identical | 21:14 |
| jam | to your series of commits | 21:14 |
| jam | (looms do this in a different way, by representing your series of patches by a series of *branches*) | 21:14 |
| jam | 2) People feel that extra "merge trunk" commits are "useless and ugly and wasteful" | 21:15 |
| jam | so they want to keep popping their changes to make them seem based on whatever the latest tip is | 21:15 |
| awilkins | Ah, so 2) is so you can just "pull" | 21:15 |
| jam | awilkins: something like that | 21:15 |
| pickscrape | I think they call it 'fast forward' don't they? | 21:15 |
| awilkins | I would find that less informative... | 21:15 |
| jam | 3) reordering history because you accidentally did things out of order | 21:16 |
| jam | like you committed | 21:16 |
| awilkins | I mean, the London Underground Diagrams are useful | 21:16 |
| jam | feature-a, feature-b, update-to-a, update-to-b | 21:16 |
| jam | and you want "feature-a, update-to-a, feature-b, update-to-b" | 21:16 |
| awilkins | Hmm. Well, now the knowledge is implanted, maybe my sunconscious will find a use for it | 21:17 |
| jam | awilkins: my personal feeling is that merge commits can be more than just "necessary" but actually quite informative and useful | 21:17 |
| jam | look at bzr.dev | 21:17 |
| jam | every commit is a merge commit | 21:17 |
| jam | and 'bzr log --short' gives you a great feature-by-feature of what has changed | 21:17 |
| jam | fast-forward doesn't have any way to give you that | 21:17 |
| pickscrape | No, it stops you from seeing the wood for the trees | 21:17 |
| jam | which is one reason why you rebase | 21:18 |
| awilkins | I agree ; a frustration with my current development habit is that it's highly subversion-informed and all my commits are in one boring straight line | 21:18 |
| jam | because you see all patches all the time | 21:18 |
| jam | so they should all be "pristine" | 21:18 |
| jam | I've moved on to a model where my feature branches can be as broken as I need them to be to make forward progress | 21:18 |
| pickscrape | qlog does a great job of allowing you to 'expand' them at will too. | 21:18 |
| jam | as long as at merge time, they are polished | 21:18 |
| jam | pickscrape: I <3 qlog | 21:18 |
| jam | it is what I wanted from "bzr viz" for a long time | 21:19 |
| pickscrape | I didn't until a few days ago. And then the next day it broke for me and won't work any more :( | 21:19 |
| luks | I think the most common use case is that you have committed a revision, now you want push and you realize the branch it out of date | 21:19 |
| jam | I tend to make incremental commits that are more "logical" based, rather than having to have the whole test suite polished at each step | 21:19 |
| awilkins | jam: I started using sibling-switch which is why I submitted that patch that makes it work with heavy checkouts | 21:20 |
| pickscrape | jam: do you have any problems with column resizing in qlog? | 21:20 |
| awilkins | jam: It could also do with sibling-switch-and-push-a-new-branch-if-it-isn't-there-and-switch-nicks-too | 21:20 |
| jam | awilkins: sure, I just do it with lightweight ones in a local shared repo | 21:20 |
| jam | and I can see the utility of "bzr switch --create-it" | 21:21 |
| awilkins | jam: I used heavies because the repo is on a thumbdrive and I might leave it somewhere | 21:21 |
| jam | pickscrape: I haven't used it in a "recent" version | 21:21 |
| jam | maybe 1-2 weeks ago | 21:21 |
| luks | in that case you can either merge the push branch into your branch, and create one extra commit or rebase | 21:22 |
| luks | using rebase instead of regular merge is just insane, IMO | 21:22 |
| brl4n | hola | 21:23 |
| awilkins | luks: The project I've been using bzr for is doing just that workflow - they need diff reports as if "rebase" had been done ; so I'm doing a merge from trunk into branch before diffs, and then a merge to trunk after ; conflicts get resolved in the branch, not hte trunk | 21:23 |
| awilkins | This was before I understood rebase | 21:24 |
| awilkins | But I still think it's valid and useful | 21:24 |
| jam | brl4n: You had problems with sftp and winxp, right? | 21:24 |
| jam | Are you using plink? | 21:24 |
| awilkins | I think paramiko is a better bet pageant / paramiko seems to work best for me | 21:24 |
| brl4n | jam:yeah I am still having problems. I am not using plink (to the best of my knowledge). | 21:25 |
| jam | brl4n: what 'ssh' are you using then? | 21:25 |
| jam | cygwin ssh? | 21:25 |
| jam | I think you mentioned 'openssh' earlier | 21:26 |
| brl4n | yes I actually installed the copssh package | 21:26 |
| awilkins | copssh is a server package, isn't it? | 21:26 |
| brl4n | awilkins:client and server yes | 21:26 |
| brl4n | i was able to remotely ssh and sftp using various clients without any problems so I'm not sure what to do | 21:27 |
| awilkins | brl4n: Try paramiko | 21:27 |
| awilkins | http://www.lag.net/paramiko/ | 21:27 |
| awilkins | Unpack it and run Python setup.py install | 21:28 |
| brl4n | okie | 21:28 |
| awilkins | Then set your BZR_SSH environment variable to "paramiko" (or delete it, I thikn it's paramiko by default) | 21:29 |
| luks | awilkins: using rebase does make sense only if you have a few local revisions | 21:29 |
| awilkins | luks: My users are well chuffed with how much faster than their old merge process it is | 21:29 |
| awilkins | luks: Previously they had to painstakingly re-do any work that conflicted | 21:30 |
| luks | awilkins: I probably wouldn't use rebase in a state where I need to resolve conflicts | 21:30 |
| awilkins | luks: Well, since I've proved that trunk > branch > trunk works, I'm not about to kick the wasps nest | 21:31 |
| brl4n | why doesn't windows just come w/ ssh | 21:31 |
| brl4n | so bizarre | 21:32 |
| awilkins | Because they prefer RDP ; it just fits their worldview better | 21:32 |
| brl4n | cause everyone uses RDP!? | 21:32 |
| awilkins | Besides, you ever try to admin an NT 4 box with just a command prompt? | 21:32 |
| brl4n | no sir. | 21:33 |
| awilkins | Neither have I, I'm too afraid :-) | 21:33 |
| brl4n | didn't know NT4 was still running | 21:33 |
| awilkins | I'm prepared to bet there are still some out there, in hide-bound places | 21:33 |
| awilkins | It was running the email service in my last place far beyond it's sell-by date | 21:34 |
| brl4n | ugg, terrible | 21:34 |
| awilkins | Truly. I think it had a 2GB limit on TOTAL email. | 21:35 |
| awilkins | There was one mailbox in marketing that had nearly half od it crammed with PPT files | 21:35 |
| brl4n | that doesn't sound impossible | 21:36 |
| brl4n | always odd limits everywhere with windows | 21:36 |
| brl4n | not even sure why I bother with it anymoe | 21:36 |
| awilkins | For me 1) Games 2) Because it's what they have at work and a lot of their old crap is tied to it | 21:36 |
| brl4n | does python 2.5 come with the crypto built in | 21:36 |
| awilkins | brl4n: I think you need to install pycrypto too | 21:37 |
| brl4n | or do I still need http://www.amk.ca/python/code/crypto.html | 21:37 |
| jam | or if you have easy_install it is just "easy_install paramiko" | 21:37 |
| * brl4n likes "easy " anything | 21:37 | |
| jam | easy_install should bring in dependencies | 21:37 |
| * awilkins has clearly been doing this the hard way | 21:38 | |
| awilkins | Do you just run the script at http://peak.telecommunity.com/dist/ez_setup.py | 21:39 |
| jam | alternatively, you can do setuptools directly: | 21:39 |
| jam | http://pypi.python.org/pypi/setuptools#windows | 21:39 |
| jam | I just found the peak site to be *very* slot | 21:39 |
| jam | slow | 21:39 |
| jam | awilkins: generally | 21:40 |
| jam | And that gives you an "easy_install" program | 21:40 |
| jam | and then you can use that to install anything in the python cheese shop | 21:40 |
| jam | I believe bzr is even in there | 21:40 |
| jam | though we don't always play nicely wrt plugins | 21:40 |
| jam | because cheeseshop doesn't like installing into bzrlib/plugins | 21:40 |
| awilkins | I just roll my own python-installer | 21:42 |
| awilkins | But I accept that this is beyond the typical call of duty | 21:42 |
| jam | awilkins: well, easy_install does the download and then runs 'setup.py install' (effectively) | 21:43 |
| jam | But it does manage dependencies | 21:43 |
| jam | and some other bits | 21:43 |
| fullermd | jam: What's the current hand-wavy 1.6 time? | 21:43 |
| jam | It *does* mean that you need a compiler | 21:43 |
| awilkins | jam: Yes, that's the nasty bit | 21:43 |
| jam | fullermd: I was considering today, but I'm thinking Monday | 21:43 |
| awilkins | jam: As you've probably discovered | 21:43 |
| awilkins | jam: You're using MinGW, yes? | 21:43 |
| jam | awilkins: well, mingw32 works pretty wel | 21:43 |
| jam | I have a VS7 install disks somewhere from when I was at Uni | 21:44 |
| jam | It is a shame you can't find the free download anymore | 21:44 |
| * awilkins is using MSVC because mingw just doesn't work well when you're linking to stuff that was also built with it | 21:44 | |
| awilkins | I have a link for the free download somewhere | 21:44 |
| jam | awilkins: "wasn't" ? | 21:44 |
| awilkins | Was also built with MSVC | 21:44 |
| awilkins | Sorry, unclear | 21:44 |
| brl4n | well, i dunno what to do | 21:44 |
| brl4n | don't feel like learning python | 21:45 |
| jam | brl4n: My recommendation would be to get plink + pageant, and to use the standalone win32 install | 21:45 |
| jam | which should include paramiko | 21:45 |
| jam | which can talk to pageant | 21:45 |
| jam | and pageant can manage your ssh keys | 21:45 |
| brl4n | yah I already tried that and kept gett'n that EOF error | 21:45 |
| awilkins | Wait until you need a bzr feature... then you feel like learning python :) | 21:45 |
| brl4n | too many dependencies | 21:45 |
| luks | if you were getting errors with the standalone installer then it's probably a bug and should be reported/fixed | 21:46 |
| brl4n | well it is just re: ssh/sftp | 21:46 |
| brl4n | everything else is working great | 21:47 |
| awilkins | jam: http://xona.com/2004/06/29.html | 21:48 |
| jam | awilkins: sure, as long as you trust 'xona' :) | 21:48 |
| jam | I mean, they have "spyware free" in their title | 21:48 |
| jam | no reason not to :) | 21:48 |
| awilkins | jam: Heh, yes. I have a download of it from another source, I could compare the two | 21:49 |
| jam | more seriously, thanks | 21:49 |
| awilkins | Can't find the "other source" though | 21:49 |
| brl4n | thanks for your help guys. I'll try back in a few months. | 21:51 |
| brl4n | cheers | 21:51 |
| hendrixski_work | awilkins: so you're saying git switches directories under the hood to do that? and.. now I gotta google what rebase is :-p | 22:03 |
| awilkins | hendrixski_work: You don't need to know what rebase is ; git has a "every dir is a repo and can hold branches" philospohy | 22:04 |
| awilkins | What he's doing is switching between those branches | 22:04 |
| awilkins | Then he rebases (gogole git-rebase or bazaar rebase) | 22:04 |
| awilkins | Bazaar can do the same, but it's a couple more steps to set up. | 22:04 |
| hendrixski_work | awilkins: ah, yeah there's a plugin for it | 22:05 |
| awilkins | Bazaar can switch branches. One thing that struck me about that video is how _quiet_ git is | 22:05 |
| awilkins | It doesn't tell you very much ; bazaar tells you what's going on when you switch, 'tis a lot more comforting IMHO | 22:06 |
| hendrixski_work | awilkins: yeah, I've never used git myself, so seeing that video was like "wow, that's pretty quick and clean" | 22:06 |
| hendrixski_work | kind of like the old UNIX philosophy of "silence is golden" | 22:06 |
| hendrixski_work | ya know, not giving output unless there's something wrong | 22:07 |
| awilkins | Yes, that's nice too | 22:07 |
| pickscrape | That's funny. I seem to remember git being criticised for being overly verbose. | 22:07 |
| hendrixski_work | lol, I just never tried it because I heard it was too hard for mere mortals to use, just those hard-core kernel developers | 22:08 |
| === fta_ is now known as fta | ||
| hendrixski_work | but that video didn't seem that way at all | 22:08 |
| hendrixski_work | I'll have to watch it again and look for rebase related stuff, maybe try it in bzr over the weekend | 22:09 |
| pickscrape | I found that it got pretty complex as soon as you wanted to dig even slightly deeper than the most basic of operations. | 22:09 |
| pickscrape | I certainly didn't want to inflict it on my team... | 22:09 |
| awilkins | The guy in the video uses rebase, but it's not really necessary | 22:09 |
| awilkins | He could have just merged | 22:09 |
| pickscrape | I'd have been lynched. | 22:09 |
| awilkins | The core of his point was "switch is great" ; rebase is more like him picking his nose while he does it | 22:10 |
| awilkins | jam: Comparing those MSVC installers they look mostly the same (alas, my other one is the 1.00 version the new one is 1.01) | 22:11 |
| luks | pickscrape: btw, I've just fixed the qlog problem you were having | 22:12 |
| pickscrape | luks: I just got the email notification, well spotted :) | 22:12 |
| pickscrape | I tried digging into it but I've never used QT before so I was a little lost :) | 22:12 |
| hendrixski_work | sooo... what is the technical term for doing that, where it appears to be like several branches in just one directory... "switch"? "rebase"? | 22:12 |
| pickscrape | I didn't see anything obvious in the BT changelog to explain it. | 22:13 |
| pickscrape | QT * | 22:13 |
| luks | I'm really surpsised they broke the API on a minor release | 22:13 |
| luks | but at least it's in the changelog | 22:13 |
| pickscrape | Can qbzr work around it, so is that version of pyqt basically broken for qlog? | 22:14 |
| pickscrape | One of my problems with git was, ok so you have a directory that contains branches. But that directory is itself a branch of the upstream repository. So you have a branch of branches. | 22:14 |
| awilkins | Grr, people need to mark their setup packages as needing UAC on Vista | 22:14 |
| pickscrape | And that contains tracking branches for upstream and local branches too. | 22:14 |
| luks | pickscrape: it's already fixed | 22:15 |
| pickscrape | So you have some sort of multi-dimensional branch thing going on and it just made my head hurt. | 22:15 |
| pickscrape | luks: oh cool! | 22:15 |
| * pickscrape updates | 22:15 | |
| hendrixski_work | pickscrape: right, it sounds terribly confusing | 22:16 |
| pickscrape | luks: I misread your first message and didn't read the 'fixed' part :) | 22:16 |
| awilkins | Holy hell, QT is large | 22:17 |
| luks | awilkins: it does lots of things! :) | 22:17 |
| awilkins | All this talk of QBzr | 22:17 |
| awilkins | Yeah, but GTK is small | 22:17 |
| luks | GTK is only a GUI library | 22:17 |
| awilkins | I only want a GUI :-P | 22:18 |
| awilkins | I'm a philistine, I'm still on QT 3 on my MythTV box | 22:18 |
| pickscrape | qbzr has leapfrogged bzr-gtk for me just recently because of the folding in qlog. | 22:18 |
| awilkins | I'm going to try it out | 22:18 |
| awilkins | I just hav eot wait 9 more minutes to do so because QT is 149 MB | 22:19 |
| luks | how are you installing it? | 22:19 |
| awilkins | Windows installer | 22:19 |
| luks | install PyQt, not Qt | 22:19 |
| pickscrape | luks: your fix works perfectly for me :) | 22:19 |
| luks | the PyQt installer contains everything | 22:19 |
| awilkins | luks: Oh. | 22:19 |
| luks | and it's much smaller | 22:19 |
| luks | at least used to b e :) | 22:20 |
| luks | or just get the qbzr installer | 22:20 |
| awilkins | luks: The error message says "PyQT 4.1 and QT 4.2" | 22:20 |
| luks | if you don't want to hack on qbzr, it should work fine | 22:20 |
| awilkins | So I got the impression I needed QT | 22:20 |
| luks | do you _have_ PyQt installed? | 22:21 |
| luks | oh | 22:21 |
| awilkins | Not yet | 22:21 |
| luks | yeah, there was a version mismatch between PyQt and Qt, so we needed different versions | 22:21 |
| * awilkins downloads pyqt 4.4 | 22:21 | |
| luks | but I agree it's a bit confusing | 22:21 |
| pickscrape | I can close all of those pyqt tabs I had open in firefox now :) | 22:22 |
| awilkins | Whee, huge numbers of errors | 22:25 |
| awilkins | Is this the bug? | 22:25 |
| luks | IndexErrors in qlog? :) | 22:25 |
| awilkins | Yup | 22:26 |
| * awilkins pulls qbzr | 22:26 | |
| luks | that is what started this conversation :) | 22:26 |
| luks | it's an API break in PyQt | 22:26 |
| awilkins | Aha, shint | 22:26 |
| awilkins | Shiny | 22:26 |
| pickscrape | luks: on my other machine I have a different problem with qlog :) | 22:26 |
| pickscrape | luks: It's impossible to get the columns to size nicely | 22:26 |
| luks | pickscrape: resize them from the other side | 22:27 |
| luks | pickscrape: the message column is not resizable, and always expands, so you need to resize the other columns from the right side | 22:27 |
| pickscrape | Yeah, I try that and it goes on a crazy dance, never settling on anything suitable | 22:27 |
| pickscrape | e.g. right now date is about as wide as half of the screen | 22:28 |
| luks | weird, if you just drag the separator between Date and Author it doesn't work? | 22:28 |
| pickscrape | If I try to shrink it (from the right side), the columns just start jumping around frantically, and letting go just leaves things pretty much as they were | 22:29 |
| luks | hmm | 22:29 |
| awilkins | Is there a place where it stores it? | 22:29 |
| awilkins | (the column sizing) | 22:29 |
| luks | qbzr.conf in bzr config directory | 22:30 |
| awilkins | Trash it and try again? | 22:30 |
| luks | pickscrape: what Qt style are you using? | 22:30 |
| pickscrape | Hmm, I'm running gnome, so I don't think I ever picked one | 22:30 |
| luks | should be cleanlooks then | 22:30 |
| luks | so that's not the problem | 22:30 |
| pickscrape | Is there a simple way for me to check that? | 22:31 |
| luks | well, does it look almost like the standard gnome theme? | 22:31 |
| pickscrape | Yeah, pretty much | 22:32 |
| luks | no idea what's the problem | 22:32 |
| luks | but if you delete the qbzr config file, at least it will reset to default sizes | 22:32 |
| pickscrape | After deleting qbzr.conf, message is now allowed to be larger, but it still seems to insist on making Date huge :) | 22:34 |
| awilkins | DAng, qlog _is_ nice | 22:35 |
| === kiko is now known as kiko-afk | ||
| sohail | hey guys, I'm trying to branch a svn repo into my bazaar project | 23:11 |
| sohail | I tried bzr svn-import https://..../ | 23:11 |
| sohail | but that died with: "No repository found. Try bzr branch" | 23:11 |
| sohail | so I tried bzr branch, and it's not doing anything (just hanging) | 23:12 |
| sohail | oh, there it goes! | 23:13 |
| sohail | wow that took a while | 23:13 |
| pickscrape | sohail: as I understand it the first time to a repository takes a while as it builds up an index or something like that | 23:16 |
| pickscrape | (svn repository that is) | 23:16 |
| sohail | pickscrape, maybe! | 23:18 |
| sohail | so the repository I'm trying to mirror has like 10000 revisions... I tried to do branch -r 9000 and it claims that this revision does not exist.. | 23:18 |
| Peng_ | sohail: There may not be 9000 revisions in that individual branch. | 23:21 |
| sohail | oh, so I need to do it based on revisions to that branch but not on the whole repo? | 23:21 |
| sohail | i.e., I can't use the svn revision number? | 23:21 |
| Peng_ | sohail: Right. | 23:24 |
| pickscrape | Use a revision number that exists in that branch | 23:24 |
| pickscrape | Hmm, no. I'm cornfused :) Isn't there an svn revspec? | 23:24 |
| pickscrape | (or whatever it's called) | 23:24 |
| Peng_ | pickscrape: I dunno. Maybe. | 23:24 |
| Peng_ | FWIW, "bzr log" will show the svn revnos too, but I don't know if you can use them anywhere. | 23:25 |
| pickscrape | You might be able to do something like -r svn:<revno> | 23:25 |
| Peng_ | Oh, there is an svn: revspec! | 23:25 |
| sohail | ah! | 23:25 |
| Peng_ | pickscrape: Yep | 23:25 |
| sohail | sounds like what I need | 23:25 |
| Peng_ | I totally didn't know that. I'll remember it for the future. | 23:26 |
| * sohail crosses fingers | 23:26 | |
| sohail | so just to clarify, I have an existing bzr repo that depends on this external svn project. I can do cd /my/repo && bzr branch -r svn:FOO <svn-url> project | 23:27 |
| Peng_ | Sure, why not? | 23:27 |
| Peng_ | But bzr doesn't support anything like svn:external (yet). | 23:27 |
| Peng_ | I mean, you can put a branch inside of another one if you want to, but they won't be linked in any way. | 23:28 |
| Peng_ | And other people who branch from the outer branch won't get a copy of the inner one. | 23:28 |
| sohail | oh, damn | 23:28 |
| sohail | that's what I want to happen | 23:28 |
| sohail | so I guess I have to bzr add that new guy then | 23:28 |
| sohail | kind of lame | 23:28 |
| Peng_ | Sorry | 23:29 |
| sohail | np, thanks for your help! | 23:29 |
| Peng_ | There is work on adding that feature (and there has been for years), but it's not done yet. I dunno how far along it is. | 23:30 |
| sohail | I might as well do svn co and add that then | 23:30 |
| * Peng_ leaves | 23:30 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!