[00:00] james_w: I know of fast-export -- but as you already stated -- it's lossy [00:00] is it now ossible by design to implement something like replaying a series of commits without loosing anything? [00:01] sorry, I've meant: is it not posible... [00:06] 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:09] 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] jonnyde1: isn't that what "bzr branch" does? [00:10] that sounds like it would be its' own repository format [00:11] 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] radix: yes, indeed it does. but bzr branch creates a branch with a specific repository format. [00:11] oh, I see, you want a format-independent backup. I missed that part [00:12] radix: yes, exactly :) [00:13] jonnyde1: you could come up with a non-lossy format similar to fast-export [00:13] maybe there should be a a format-independent repository format, too. One that does not consider any optimisations regarding storage efficiency.... [00:14] 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] not really possible [00:15] 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:16] ok, that's a good point [00:17] 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] the only difference is [00:18] that I would have to be able to commit change sets created by someone else [00:18] I mean using his signature/checksum [00:20] (and original content of course) [00:23] jonnydee: I think you misunderstand what repository formats do [00:24] lifeless: probably you are right... [00:24] jonnyde1: there are two different dimensions in formats [00:24] jonnyde1: one is _model_, one is just how things are indexed etc [00:25] the latter is things like knits -> packs -> btree etc [00:25] the former is things like 'plain', 'subtree', 'richroot' [00:25] its not possible to predict the future [00:25] so its not possible to define a model which is accurate in the future [00:26] 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] well, when they have the same _model_ that is true [00:26] but its not true when you commit to a format with different models [00:27] but the information I provide during commit is always the same, isn't it? [00:27] no [00:27] I provide my content and a message [00:27] what else? [00:27] the data on disk :) [00:27] the entire working tree is information [00:28] the unique id for files [00:28] whether there are nested trees [00:28] the UUID the commit is to be assigned [00:29] but imagine a batch script in which I create a repository [00:29] 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] but bzr will consider them to be different projects [00:29] then I do create some files, create dirs, add them, rename them, etc. [00:29] jonnyde1: sure, we do this thousands of times in the test suite for bzr [00:29] now when I execute the same script on a repository with a different format, it just works [00:29] jonnyde1: and every single time they are unique [00:29] ok, now I see [00:29] jonnyde1: the script works, the identity of the content is different [00:30] so you would also get different revision ids? [00:30] yes [00:30] and different file ids [00:31] and how do you implement upgrade/downgrade without stumbleing over the same issues? [00:31] we're working with the structured data [00:32] actually, there is a logical argument here: [00:32] if you define something that stores the very minimal data needed to exactly reproduce a bzr repo [00:32] you have defined a bzr repository format [00:33] its no more neutral than the formats we ship in bzr itself [00:33] makes sense... [00:33] 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] if it looks like a duck, smells like a duck, and quacks like a duck, might as well call it a duck [00:35] and why doesn't svn have to deal with this issues? is it because there are no cryptographic ids? [00:35] svn has the same issue [00:36] 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] you have to dump and restore svn repositories to upgrade them on the back end as well [00:36] I don't know why svn is not _percieved_ to have the same issues, but it has them :) [00:37] but I can dump the contents of 1.4 and import them into 1.5 -- and vice versa [00:37] without loss of information ... AFAIK [00:37] you can downgrade a bzr repository from packs-0.92 to knits without loss of information [00:37] because thats simple layout, not data model [00:38] 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] ok, I think I am starting to understand.... [00:40] 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] jonnyde1: sure there is [00:41] jonnyde1: bzr upgrade sftp://.... --format=FORMATNAME [00:41] some format choices are one-way, because there is data loss going backwards [00:41] it told me something like downgrading from that format is not implemented yet... [00:41] but the default is not like that, you would have to have explicitly chosen a format that is past that one-way barrier [00:42] jonnyde1: whats the branch url? [00:42] yes, now I understand why. It's indeed a by design issue [00:42] well I removed the branch completely and created a new branch with an older format [00:43] jonnyde1: what was the format you had used? [00:43] and locally I threw away my history and created a new branch with new revisions from scratch [00:43] I used --rich-root-pack, I think. But just a moment... [00:44] jonnyde1: ok, *why* did you do that? [00:44] jonnyde1: its not the default for a reason :) [00:45] 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] jonnyde1: you should only use defaults unless you have a specific reason to use something different [00:46] 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] well, that sounds reasonable. But on the other hand there isn't any suggestion to do so in the documentation or bzr help [00:47] bzr help formats: [00:47] ... [00:47] rich-root-pack: [00:47] (native) New in 1.0: Pack-based format with data compatible with [00:47] rich-root format repositories. Incompatible with bzr < 1.0 [00:48] well, but I am always using the newest bzr version [00:48] jonnyde1: then why did you dislike the behaviour of rich-root-pack? did something go wrong? [00:49] the problem was I upgraded my local repository to the newest rich-root-pack format [00:49] then I had to do the same with the one hosted on launchpad [00:49] yes [00:50] because bazaar told me the formats were incompatible [00:50] thats normal for rich-root changes, what went wrong though? [00:50] launchpad was not comfortable with a repository format named 1.7dev and rich-root-pack [00:51] lp handles rich-root-pack fine [00:51] so actually nothing went wrong except that launchpad had a problem with it [00:51] lp won't handle development formats, because it runs bzr releases [00:51] but it told me that 1.7 is not supported [00:51] bzr has not released 1.7 yet [00:52] lp only supports released bzr versions [00:52] yes, exactly. so I tried to downgrade it again [00:52] and this is where I got stucked [00:52] if you downgrade to rich-root-packs it would have worked [00:52] ok, for future reference - launchpad supports bzr released versions only [00:53] you can upgrade between any format version that has the same data model [00:53] 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] so *-rich-root are all compatible with each others [00:53] you can delete backup.bzr there using hitchhiker [00:53] and the second try exited with the message that there is already a backup.bzr [00:53] its a bug in lp that thats not easily removable [00:53] I'm sorry you had trouble [00:54] lifeless: no problem -- really!!! :) [00:54] and more sorry you didn't get good support :( [00:54] I mean I lost some revisions from history but there were only a few until now, anyway [00:54] it was a fresh project [00:55] And it was my fault to use a development version of bazaar [00:55] So please don't mind ;) [00:55] ok :) [00:56] 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] and regarding support: I couldn't get better support :) [00:56] what you need to do is do 'bzr init --MODEL lp:..' rather than just a 'push' [00:57] 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] ok, thanks -- I will do that, instead [00:59] lifeless: thank you very much for taking the time to answer my questions. It is really really nice of you :) :) :) [00:59] my pleasure [01:00] So have fun and a nice day/night . best regards [01:00] thanks, I shall! [01:23] jml: lol @ forcing you to use a dictionary :) [01:24] hey guys [01:25] 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:26] bzr push URL ? :) [01:26] over http? [01:27] sorry my brain is fried today but I fear this is as good as it is going to get! [01:27] sure, if you have bzr configured in your apache config and use https rather than http [01:27] or you can use sftp or bzr+ssh [01:27] ah [01:28] so I hate mucking around with apache... Can I do it without telling Apache this is bzr? [01:29] is you isntall the webdav plugin and enable webdav on your server (and use https :)) [01:29] most people use bzr+ssh or sftp though [01:29] so how do I let people clone it then? [01:29] like I don't care about pushing over ssh, that's what I do now [01:30] but I don't know how to let people clone it [01:30] again, please refer to brain fried state above if this sounds totally stupid [01:31] just have the place you pushed to be served by apache [01:31] over plain http? [01:31] sweet [01:31] no futzing around with apache? [01:31] double sweet [01:35] so do you guys have one bzr repository for all your projects or multiple repos [01:35] multiple repos, on the whole [01:36] I see [01:36] what are the benefits? [01:39] mwhudson, I'm not a bzr expert but what do you do when one of your projects depends on another? [01:40] sohail: symlinks, basically [01:40] but i'm not really responsible for the setup or deployment side of things [01:41] you non-windows user you [01:41] :) [01:41] there's no real disadvantage to one-big-repo, i think [01:41] symlinks are a perfect solution until you hit the dreaded C:\> prompt [01:43] 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] and/or provide variables to build on an uninstalled copy [01:44] mebbe [01:44] not a huge deal anyway [01:44] now next question :-D [01:44] how can I track a svn repository in bzr? [01:45] various ways [01:45] request an import on launchpad [01:45] or bzr-svn [01:45] being the two main ways [01:45] bzr-svn sounds promising === andreas__ is now known as ahasenack [02:08] let's say [02:08] I have a file in one branch that has its own history [02:08] how do I bring that file into another branch with full history? [02:08] file histories don't have log messages, you need the full branche for that [02:08] so you'd do bzr join to join the branches [02:08] gotcha. [02:46] so [02:46] is having some big files in .bzr/repository/upload normal? [02:47] can I kill them? :-( [02:48] they are temporary files during commit/push/pull/merge [02:48] if you have no bzr processess doing that, then yes. [02:48] thanks [02:48] should they not be cleaned up the next push or so? [02:48] they only get left if bzr gets disconnected/physically interrupted [02:48] well [02:49] kiko: we can't tell if they belong to an active process, so no. [02:49] the funny thing is that this file is 300MB, but the actual .bzr folder itself is about 1MB [02:49] probably you interrupted a bzr push of launchpad to that repo :) [02:50] could it have been a bzr merge? [02:50] sure [02:50] ah, then that's what it was [02:50] how could you guess?! [02:50] I know how big launchpad is :P [03:06] jelmer: don't suppose you had any luck tracking down that issue today ? [03:27] rocky, I did [03:27] oh? something i can test? [03:27] It should work now, haven't tried with your URL though [03:27] rocky, 0.4 branch [03:27] * rocky tries [03:29] jelmer: while i'm waiting for this to checkout ... do you use tracbzr much? [03:30] Why have bzr-svn default to 1.6-rich-root? [03:30] rocky, yeah, we use it for bitlbee and ctrlproxy [03:30] Peng_, Seemed like a sane choice since it'll only work with bzr 1.6 anyway [03:30] jelmer: oh, should i be creating my repo with --rich-root-pack or 1.6-rich-root ? [03:30] rocky, either will work [03:31] jelmer: another error --> http://cluebin.appspot.com/pasted/801 [03:31] rocky: 1.6-rich-root supports stacking, but isn't compatible with older versions of bzr. [03:32] rocky, sorry, uncommitted change [03:33] jelmer: let me know when your'e ready [03:33] rocky, please try again [03:34] jelmer: k, recreated repo and checking out the svn source again [03:37] jelmer: well, the checkout is taking a lot longer this time ;) [03:41] the amount of http requests this is doing for a checkout is astounding [03:41] * rocky is watching his remote server logs [03:42] 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:43] rocky: it needs to search for revisions not on the mainline [03:44] 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] rocky, incremental commits should be faster [03:44] define: incremental commit [03:45] rocky, if you do another commit, it should be faster [03:45] if not, how fast is it? [03:46] 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] this 2nd commit is taking longer than the first one did [03:47] rocky, It has to check whether the revision is already present elsewhere [03:47] rocky, since bzr does a push under the hood [03:49] jelmer: added a 2nd file... [03:49] time bzr commit -m "Another checkin test" [03:49] Committing to: https://dev.serverzen.com/svn/cluemapper/ClueMapper/trunk [03:49] added test.txt [03:49] Committed revision 113. [03:49] real 1m4.238s [03:49] user 0m2.168s [03:49] sys 0m0.148s [03:49] (bzr-1.6)rocky@zebrax:/usr/misc/apps/bzr-1.6/sandbox/repo/ClueMapper-trunk$ [03:49] whoops, sorry [03:49] didn't realize it was so much [03:50] rocky: This is bug 158657 [03:50] Launchpad bug 158657 in bzr-svn "ability to limit paths searched by lookup_revision_id()" [Medium,Triaged] https://launchpad.net/bugs/158657 [03:51] jelmer: that commit that i just pasted ... did 347 svn requests according to my remote apache log [03:52] so that's my 3rd commit ... so far it seems like things are slowing down more [03:54] * rocky wonders if he's the only one having these major slowdown issues [03:58] You're not [04:01] rocky, do you have a lot of directories on the same level as your branch? [04:04] 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:05] rocky, there's a lot of things at the same level it looks like [04:05] it'll check https://dev.serverzen.com/svn/*/* [04:05] jelmer: lol how's that the same level? [04:06] same level of nesting in the repository [04:09] jelmer: shouldn't you be asleep? :) [04:10] jelmer: hmm.... so where does this leave us? :) [04:10] mwhudson, yes, I *should* :-) messed up biorhythm again [04:10] rocky, it'll be slow for a while, until bug 158657 is fixed [04:10] Launchpad bug 158657 in bzr-svn "ability to limit paths searched by lookup_revision_id()" [Medium,Triaged] https://launchpad.net/bugs/158657 [04:11] 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] rocky, alternatively, you can just work in bzr and push to svn in batches [04:12] 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:13] i took that line for a while [04:13] then i just gave up and switched 100% to bzr [04:14] rocky, what I mean is, you don't have to use a checkout [04:14] rocky, you can just use bzr and maintain a mirror in svn using bzr-svn [05:51] abentley: welcome back :) [05:52] lifeless: thanks. [06:22] heh, wb bb [06:39] * vila warms up, reset clock, 22min to go to start at 08/08/22 08:00 [06:49] vila: :) [06:58] * vila 's internal security check failed, caffeine too low. launching delayed by ~8mins [06:59] rotfl [07:01] jam: isn't it your bedtime ? :) [07:08] 08/08/22 08:08:22 IGNITION [07:08] Hello World ! [07:10] welcome :) [07:11] lifeless: thanks :) [07:14] vila: hi :) [07:17] mwhudson: hi ! [08:59] Is there a way to "svn checkout" using bzr without downloading full history? [08:59] Just a "get me started RIGHT NOW" basically? [08:59] only downloading history when needed, e.g. for diffing [09:00] or just the last few revisions [09:01] uws: I belive the answer is 'yes'; bzr checkout --lightweight will get you a 'this revision only' checkout, I believe. [09:01] hmmm. will that work for foreign svn branches as well? [09:01] probably, but it will still need to cache all the revision metadata [09:02] but I probably shouldn't be saying this if I'm not sure :) [09:02] it would be a killer feature for many ppl forced to use svn today [09:03] importing like ~10000 revisions into bzr is NOT fun [09:03] can take > 2 days [09:03] stacked branches may give you that [09:03] at some point [09:23] hello all [09:23] how to set permission to access particular folder alone for a particular user [09:23] bzr doesn't support that, sorry [09:24] except by making it its own branch [09:25] bob2, who will make that? users they themselves [09:25] but svn has this feature know? [09:26] sorry, I don't understand the first part of your question [09:26] but I believe svn lets you set permissions on particular paths in a repository [09:26] bob2, yes.. [09:27] making it its own branch? [09:27] uws: 'bzr branch --stacked' I believe, should work now [09:27] means...user will create the branch as own branch? [09:28] you can restrict access to branches, just not to particular dirs within them [09:29] bob2, ok how to do that [09:29] just create the branch and set the unix permissions on it so only they can access it [09:29] assuming you're on unix [09:39] lifeless: this stacked branch will cache locally? [09:39] lifeless: and can I convert it to a real branch, e.g. overnight when I'm not using it? [09:41] uws: you can just branch from it again to make it full [09:42] 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:43] lifeless: so it's basically a "smart" branch that only pulls when really needed. [09:43] so that I can start hackign right away [09:43] use case: work on $project which is hosted in svn, it has like 1000 revisions [09:43] yes, and one that needs to be connected to the real server - because it doesn't have everything locally [09:43] and I don't want to touch svn ;) [09:44] and I do want to get started right away [09:44] uws: yes, thats the use case for it - avoid downloading deep history [09:45] lifeless: will "bzr log" require all history? [09:45] uws: naturally [09:45] uws: unless you do --line or whatever, it will do it incrementally as normal [09:46] lifeless: (I thought perhaps commit log messages are stored separately from the actual diffs) [09:46] anyway, this is 1.6 only right? [09:46] right [09:46] uws: it will access just the commit messages from the remote server [10:59] Can I define my own prefixes, just like lp: ? [11:00] only using a plugin [11:00] but you might want https://launchpad.net/bzr-bookmarks instead? [11:01] it allows you to define aliase and then bm: [11:01] or bm:/some/other/subpath [11:02] this plugin was originally written only as a joke, and turned to be probably the most useful plugin I wrote :) [11:02] haha [11:04] any recommendations how to install bzr on a sles9 system? [11:04] download the tarball and python setup.py install? [11:05] (I expect the packaged version to be ancient) [11:06] sles features python 2.3 [11:07] so I'd first have to deploy python2.5 first.. that's why I ask if someone had already done that [11:08] oh [11:08] bzr py2exe installer + wine [11:13] luks: trying your bm plugin now. can I use for prefixes as well? [11:14] uws: not for lp: like prefixes [11:14] uws: but you can use bm:/some/other/path instead of yourprefix:some/other/path [11:16] luks: Thanks, got it to work! [11:17] bzr log bm:ilps/PROJECT/BRANCH works ;) [11:17] (ilps is my university department/group) [11:35] siretart: 2.4 is all we need [11:35] siretart: can you get python 2.4 for sles9? [12:05] lifeless: sles9 only ships python2.3. I have now installed python2.5 in a private, user writable path [12:05] now I have a working bzr 1.6rc5 :-) - now let's get this cvsps thing working [12:06] I assume that version 1.99-152.1 is stone age, right? [12:07] no idea :) [12:07] <- Ubuntu/Debian only :P [12:29] isn't there a cvsps branch on launchpad somewhere? [12:29] does cvsps upstream still exist at all? [12:38] gnight [12:38] siretart: I don't know, I would tend to apt-get source :P [12:40] yeah [12:47] 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:54] * kiko reminds siretart of his debts to society :-P [12:55] Surely 10 years of using CVS is enough to work off any debt :-P [12:57] 10 years of CVS? it sounds as eternity...i'm (was) not ready for it :-) [12:57] 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... [13:06] 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:07] kiko: hey, I also have a real job :-) [13:07] You "win". :p [13:08] siretart, no you don't!! [13:10] * awilkins knows more about MKS that he wants to know [13:10] MKS is based on CVS. [13:10] With added evil [13:14] <\3TATUK> Which port does the bzr smart server use default? [13:17] is bzr native faster then bzr+ssh? [13:22] 4155 [13:24] how to do an iter_changes from revision 0 to the first one? [13:25] 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] 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:30] fullermd: I use the ssh controlmaster stuff for most of my connections anyway... so setup/auth/teardown time doesn't happen [13:35] 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:36] It can get a bit annoying on occasions, in those rare few times you -want- a new connectin [13:36] E.g. when upgrading an ssh server [13:54] bazaar works on python2.3? [13:54] hsn_: no, you need at least 2.4 [13:58] sadly we have centos 4.6 on all our servers [14:09] Yay [14:09] project at $work (univ) has officially switched from SVN to Bazaar! [14:14] hi [14:15] it always complain "You have not informed bzr of your launchpad login.." [14:15] what should i do? [14:15] im a newbie [14:17] bzr launchpad-login USERNAME [14:18] is that a problem? :) [14:27] yes [14:28] luks [14:28] yes, what i should input? [14:28] didn't I say it already? [14:29] what did you say [14:30] should i input 'bzr launchpad-login em1'? [14:30] em1: bzr launchpad-login USERNAME [14:30]