=== james_w` is now known as james_w === Toksyury1l is now known as Toksyuryel === verterok` is now known as verterok [14:08] hi. [14:08] I have installed bzr on windows. [14:08] how do I run bzr explorer ? [14:09] (I understand it is a part of bzr distribution) [14:19] sobersabre: it's a separate plugin [14:26] The Windows distribution puts a shortcut on the desktop by default [14:27] Or you can start it on the command line with `bzr explorer` , I think [14:59] awilkins: thanks! [15:00] I will try this. [16:41] ./bzr/branch/location makes bzr choke when an editor adds EOL to the end of that file [16:41] ack to fix that? [16:47] lifeless: ^ ? [18:34] moin [18:35] i'm using the text-checker-plugin to avoid adding tabs and trailing whitespace and similar in commits [18:35] but the pattern matching is driving me crazy [18:35] [name Makefile.am] [18:35] this appears to get ignored [18:36] below i have "[name *]" with default actions [18:36] tabs are allowed in Makefile.am but nowhere else [18:36] but the first section never appears to get triggered [18:36] any hints? [19:00] is there way to convert repote repo (which i dont admin) to bzr? [19:00] svn repo [19:00] hsn: yes [19:01] let launchpad to import it? [19:01] hsn: if you have a project page you can add a source branch that is imported by launchpad from one of few foreign system [19:01] hsn: svn and git are supported, I'm sure some others are too but I cannot remember the full list like that, I only used git personally [19:02] it is one way or 2 way sync [19:02] hsn: svn has some approval process I'm not familiar with [19:02] hsn: it's just a pull, one way [19:02] hsn: but you can use bzr to commit to a svn repo so your options are wider than just that [19:02] hsn: what are you trying to do? [19:02] need mediawiki in bzr [19:02] it probably is already [19:03] ok, so it's not [19:03] https://code.launchpad.net/mediawiki [19:03] hmm [19:04] it seems you have to be the owner of the project to set it up [19:04] hsn: you can use a local branch [19:04] hsn: not bound to lp in any way [19:04] i own one project in launchpad, i will import mediawiki there [19:05] hsn: don't just import mediawiki there without a good reason [19:05] hsn: unless your projects is mediawiki clone it does not make sense [19:05] hsn: you can simply get a bzr branch of mediawiki locally [19:06] and push it to mediawiki project in lp under your own name [19:06] so bzr push lp:~yourname/mediawiki/name-of-your-branch [19:06] you can convert the svn tree locally using bzr and bzr-svn package [19:07] there are docs on how to do that but I suspect that you can just simply bzr get the svn url [19:07] I don't know what's going to happen if you want to get all the branches, this would work for svn trunk [19:08] i need 17alpha branch [19:09] hsn: then bzr get that directly [19:09] hsn: if you try it and get stuck please ask again [19:09] * zyga goes to work in another screen [19:44] any thoughts on http://paste.pocoo.org/show/310950 ? [19:45] the odd thing is that I get that behavior when using libpython, but not at the command line or in a script [19:46] hi Tak [19:46] hi! :-) [19:48] happy solstice [19:51] Tak: thanks, you too :-) [19:51] Tak: what happens if you try without the extensions built? [19:52] I don't see what's going on, after having had a quick look [19:52] Tak: In general, calling the command implementations from other code is a bad idea. Any reason for not calling branch.pull() ? [19:52] that's odd...locate tells me that extension only exists in my local bzrlib wc [19:55] mmm, I was using the lower-level api before (branch.pull) [19:56] zyga: well, its not intended for editing; bzr switch will change it for you [19:58] Tak: What made you switch? [19:58] 'morning lifeless [20:00] iirc, there were some instances where the command api was doing some error handling/special-casing that I didn't want to redo by hand [20:00] so then I just went that way across the board [20:16] lifeless: yeah but bzr colo hardcodes the _absolute_ path of the tree so I had to fix it after realizing I broke it with out-of-tree mv [20:16] lifeless: it's a simple fix that would at the very least make the behaviour more aligned with what users might expect [20:25] you can fix it with bzr switch [20:26] and the bzr code as written needed absolute paths, older versions will fail if its a relative path, so we always write abs paths. [20:27] zyga: I don't know if you're aware, but you can actually have \n in filenames :( [20:33] lifeless: then we should print the repr of the filename and still allow a newline _not_ to break this [20:33] lifeless: or do you think that I should not be able to mv my colocated branch without having it explode? [20:58] Hello [20:59] Does bzr support perforce style mainline branching strategy [20:59] does it support it out of the box [20:59] servertood: what do you mean by mainline branchinc strategy? [21:00] well I have a team on perforce [21:00] servertood: You should bear in mind that most people here, myself included, will have no idea what "perforce style mainline branching strategy" is [21:00] servertood: I used p4 for a year and a half but I never used that term before [21:00] ok well the basic mainline appraoch to branching is something they document as a workflow for using perforce [21:01] I have a team on p4 and we want an open source scm that works the same [21:01] or better.... [21:01] servertood: could you please describe the workflow? [21:03] one sec [21:06] theres a master doc [21:06] Im not finding it atm - heres a basic setup http://www.vaccaperna.co.uk/scm/branching.html [21:07] littel better http://www.perforce.com/perforce/doc.current/manuals/p4guide/06_codemgmt.html [21:09] ok I found it [21:09] http://www.perforce.com/perforce/papers/bestpractices.html [21:10] servertood: so which point explains the strategy you mentioned? [21:11] scroll down to where the heading says "mainline model" [21:11] o [21:11] so [21:11] one question [21:11] how big is your "mainline" [21:12] :-) [21:12] 250 MB? [21:12] checkout or entire history? [21:12] do you have binary files? [21:12] some [21:12] images etc [21:13] We are going to lose the history because its all garbage history anyway [21:13] the team that was using the repo all used the same user for all checkins [21:14] so there are alot of binaries that dont need to be there because its a mess but I would say 100MB check out might be right [21:14] but not a huge amount of files [21:14] lots of jar files etc [21:14] servertood: so I was in a similar situation [21:14] and I have the following to say as bzr user [21:14] 1) binaries will make you cry over bzr [21:15] hm [21:15] 2) if you switch vcs you should consider splitting the repo (say to libaries/projects/components) [21:15] that sucks [21:15] and have separate trees for that [21:15] whats the issue with binaries [21:15] just too slow [21:15] once you have that you can use bzr and you will be happy, p4 is actually so brain dead that bzr runs circles around it [21:16] they are not handled very well, the AFAIR official policy is that they are not important enough to be optimized for, if you want to version ISO files bzr will kill you [21:16] ok but what about stuff like images for webcontent [21:17] I dont want to version huge binaries [21:17] it _will_ work [21:17] right now theres some jars that may be 10 MB 50 MB stuff like that [21:17] but bzr assumes pretty much that you have to fit all the tree in memory [21:17] x2-x10 [21:17] hm [21:17] depending on stuff it does and bzr version you use [21:17] lifeless: ^^ please bash me for talking nonsense if I do [21:17] anyway [21:18] ok that sounds a little troublesome [21:18] it works very well for source [21:18] text [21:18] for binaries [21:18] so the work around again for binaries is [21:18] it works but it's not the primary use case so you may get big memory usage [21:19] so theres no - "hey for these file extensions dont load into memory..." [21:19] servertood: p4 is a versioned FTP server, really [21:19] servertood: no, for various reasons, it's not that simple [21:19] so is there a workaround [21:19] or is the workaround dont do it at all [21:19] servertood: there's been many people coming in and asking for support but nobody stepped up to do it [21:19] servertood: there is no need for a workaround, if your files are not that big then you will not notice it [21:20] servertood: if you start versioning big stuff then 1) bzr was not designed to do that 2) dvcs is not a good idea 3) it will work if you have the memory [21:20] ok so if I have a huge lib dir say for java [21:20] servertood: then again, perhaps, if you already switch to a multiple-repository model you can keep something for such stuff [21:20] 100-200 MB of jars [21:20] thats going to screw me [21:20] servertood: do you have to version them? [21:21] no because Im going to switch to maven [21:21] and not a manifest that says which version you actually need? [21:21] and pull them down during the build [21:21] but I have to version the project as it is right now [21:21] servertood: I'm not in java world but versioning binaries is not a good idea, version the source and build it [21:21] these are dependencies [21:21] like I said Im going to pull them in from a remote repo during the build [21:21] but for now [21:21] I don't put my dependencies in my tree [21:21] I have to version what I have [21:21] I know java world is different [21:22] which is a bucket of junk [21:22] servertood: what you have to version is the actual _version_ of a binary, not the actual file [21:22] I suppose I could refactor before I import [21:22] maybe that makes more sense in this case [21:22] servertood: there is little difference to saying that I need to bundle glibc and other stuff with my C project [21:23] servertood: except that for Java and SVN/p4 it works (jars will execute) and works for proprietary jars [21:23] servertood: there are two topics here though: how to work with bzr and how to design the infrastructure around janva (which I don't know about much) [21:24] i can get rid of the dependent binaries [21:24] but over time Im going to have non devs version word docs and god knows what [21:24] so if this is really just for source - Im not sure its what Im looking for [21:24] although I have remote teams [21:25] initially Ill be working in non distributed client server type setup [21:25] servertood: if your development process produces .docs then thats another mindset incompatibility [21:25] does that help the performance at all? [21:25] servertood: we would produce source files that get built to documentatino that can be versioned/compared/merged [21:25] we have specifications that need to be versioned [21:25] they are not produced by development [21:26] servertood: I cannot teach you your work as you know best what is needed [21:26] servertood: I can only say this [21:26] servertood: bzr will work great for what it's designed for [21:26] servertood: code [21:26] servertood: and text [21:26] ok [21:26] servertood: if you do the transition in a smart way your overall development model will get more complex but more powerful [21:27] servertood: if you do it in a naive way (bzr add . && bzr ci -m "yay") then you will not get anything inherintly better than p4 [21:27] servertood: apart from the hefty price for p4, what was it 1K/year? [21:27] (per seat) [21:27] its pricey [21:27] and it sucks badly [21:27] it's just a versioned FTP site [21:28] The teams I have been working on for years have no issues with it [21:28] they even ship pftpd, that versions files on uploads [21:28] But Im not an SCM expert [21:28] yeah, some of the guys I work with /rave/ about perforce [21:28] servertood: people that were always in a cage don't know how it feels outside [21:28] WHat I will say abvout it is [21:29] it never got in my way [21:29] servertood: eseentially each tool will work but current generation of vcses gives lots of new options that are just awesome for developers [21:29] Thats what Im looking for [21:29] I always found it buggy, slow, and mostly not different better than CVS [21:29] A tool that supports branching more intuitively so you can work with the tool and not be afraid of fucking up the project [21:29] you could go back and edit history [21:30] change commit messages [21:30] nothing was atomic [21:30] well Im not sure IM going to get to nirvana in this first pass [21:30] the GUI was just one gigantic script that often hangs if you are talking over a slow link [21:30] and the whole "multisite" mess is insane [21:30] :-) [21:31] I think Im going to go whole hog [21:31] and dump everythig in it [21:31] and then refactor [21:31] servertood: if you're open sourcing then perhaps giving people a look at the code and the layout will yield more educated answers [21:31] and see how the performance is [21:31] servertood: that's not a good idea [21:31] servertood: then everyone will have to get that first commit you made [21:31] servertood: it's not a centralized repo, you pay for the history [21:31] even after I refactor? [21:31] servertood: certainly [21:31] ok [21:32] servertood: do it the other way around [21:32] servertood: start adding stuff to bzr [21:32] servertood: while refactoring [21:32] servertood: and if your tools support that, break stuff up early at component boundaries [21:33] does bzr support allowing only access to parts of the tree to a user [21:33] no [21:33] this is a high security project [21:33] none dvcs does [21:33] it's not possible [21:33] if I can get anything (any revision) [21:34] so I have to have seperate repos for different access levels [21:34] yes [21:34] ok [21:34] if you can get the whole history and work offline you have to have it locally, by then no security can exist [21:34] right [21:35] so...if Im not do dist devel [21:35] ? [21:35] should I just use a centralized model [21:35] and not use bzr [21:35] ah [21:35] not really [21:35] it depends on how you define security today [21:35] I remember the days of clearcase when they said whatever you do [21:35] dont enable multisite [21:35] I know that this is built in out of the box now [21:35] I don't know how you work, do you have a team of people that can access something that other team or teams cannot? [21:35] ah clearcase [21:35] the tumor of version control [21:35] old days [21:36] * zyga shrugs [21:36] Well I actually [21:36] have to control access at the level of the developer [21:36] servertood: no dvcs has "mutisite", I hope you understand that [21:36] yes I do [21:36] servertood: and at the repository level? [21:36] servertood: developers is not what you can control in dvcs [21:36] well right now [21:37] they have code separated by env [21:37] servertood: you can only control the _trees_ [21:37] so you either get access to dev or SIT or UAT or prod but thats pointless [21:37] I need to be able to say [21:37] hey a report developer [21:37] cannot access code that does ACH transactions [21:37] important question: [21:37] why not? [21:38] is it "because the code has secret sauce?" [21:38] I dont want them to be able to change it [21:38] or "because I don't want him to screw up" [21:38] ah [21:38] that's easy [21:38] change your model [21:38] have a gatekeeper [21:38] that reviews [21:38] because its a doorway to fraud [21:38] have branches [21:38] that get reviewed and merged [21:38] nobody but the gatekeeper can commit [21:38] sure I guess your right [21:38] so [21:38] its just a high security env so [21:38] you don't care that Joe developer got a _branch_ of Foo [21:38] and changed somethng that broke it [21:39] Actually having more eyes on the code could potentially reduce fraud [21:39] you just crare that he could not get his code in the "blessed" branch of Foo [21:39] so [21:39] sure [21:39] if you can get every part of the code accessible to everyone (or just to each emploee) [21:39] then you are safe [21:39] bzr and other dvcses will work for you [21:39] so they create a branch [21:39] do their dev [21:39] merge into some other branch [21:40] I don't know how you work [21:40] but again [21:40] but can they merge into all branches? [21:40] for dvcses a very common and effective model [21:40] is to have a reviewer [21:40] so I make a branch of my project trunk [21:40] whats stops them from merging into production [21:40] hack it [21:40] and post a merge request [21:40] you can put whatever security/access around a _tree_ [21:41] so you can say that physically only that user or that grup can perform alterations in that tree (at filesystem level) [21:41] if you can opernsource your project [21:41] then launchpad will provide you an infrastructure [21:41] with code reviews [21:41] security access [21:41] and all the good stuff [21:41] teams [21:41] users [21:41] in my case that is not legal [21:41] and so on [21:41] so you cannot opensource your code as you intially said? [21:42] my code? [21:42] no I want open source tool for SCM [21:42] ah [21:42] I see [21:42] anyway [21:42] you can deploy your own infrastructure then [21:42] legally I cant do that [21:42] of have someone who will do it for you [21:42] sure Im building a new env [21:42] servertood: btw, what is your business about? [21:42] I really cant say [21:43] So if I have a release branch [21:43] servertood: so to go back to the topic: you can setup security, you can have a working workflow and it will be arguably better than a worflow where once you get commit access you can do anything [21:43] your saying I cannot prevent someone from merging into it [21:43] no [21:43] that's not what I'm saying [21:43] ok sry [21:44] bzr does not care about who is doing changes [21:44] neither does any other system [21:44] you just setup system users or other filesystel-level protection [21:44] ok thats cool [21:44] so code to /srv/bzr/something/trunk can be (for example) only changed by that user or that group [21:44] zyga, servertood: There is no official policy that binaries are "not important enough to be optimized for". In fact, there are people doing work to make bzr handle them better. [21:44] You exert security control on who is allowed to merge changes upstream into release branches [21:45] sure [21:45] at the filesystem level ok [21:45] mkanat: I remember reading about one of the bzr devs commenting that binaries are not a priority so they are not treated differently than text - that's what I meant - if that's changed then I can only be more happy [21:46] I think there are "bigfile" plugins for git and mercurial that are in some kind of usable state now [21:46] zyga: It hasn't changed, but there is work underway to change it. [21:46] mkanat: cool [21:46] mkanat: can I help in any way? [21:46] In my experience, files up to around 100MB are alright on modern machines [21:46] is there a bug open on it? [21:46] zyga: Yeah, very possibly. [21:46] how many files up to 100MB? [21:46] say I have a dir of 200 MB worth of binaries like 10-20MB each [21:46] I have several branches that consist of around 1.5GB of text data resources in text files about 60MB or more apiece [21:47] And they check out OK on a machine with 2GB of RAM [21:47] really [21:47] servertood: you might hit the memory wall when bzr repacks the data [21:47] zyga: I think jbowtie is doing the work on it, you should ask him. [21:47] It can get a little ... swappy at that point :-) [21:47] lol [21:47] mkanat: thanks, I'll ping him [21:48] AFAIR repacking crosses file boundary and just sucks the tree in [21:48] On my home desktop with 6GB of RAM and a 64-bit OS it's just fine though :-0) [21:48] anyone running Buildbot on bzr repo? [21:48] then your ISO will kill a 6GB machine [21:48] so this slow down [21:48] We have been using Maven for storing large binary build outputs in [21:49] But it's not entirely well suited to that either - more to library sized JAR files [21:49] sure [21:49] Im switching to maven [21:49] servertood: It's more about the size of individual files than the size of your whole repo, with bzr. [21:49] really [21:49] servertood: It won't deal well with a 1GB binary, but it should be fine with a 100MB binary. [21:49] Enough people (p4 using game developers mostly) raise the "big binaries" issue recently to make it worth looking at [21:50] If you are using Maven, top tip - use Nexus, not Archiva. [21:50] Im sure I dont have any files near 100MB [21:50] Nexus totally blows Archiva out of the water in terms of upload performance [21:50] mkanat: it's been my experience that repacking _will_ kill your system at that poing (having any number of 100MB files) [21:50] Im using Maven to build java [21:51] yeah, we have big binary issues as well [21:51] What I'd like to see is a system that stores big non-mergy binaries on their SHA1 sum in a glorified FTP server [21:52] YES [21:52] And you just refer to each binary you want in your build system by it's SHA1 [21:52] awilkins: that's not going to help you without pure shallow checkouts - assuming you still want dvcs [21:52] I mean, in the case of game dev, who goes with their old assets anyway? [21:52] awilkins: I've been considering transitioning part of a very large p4 repo to anything else [21:52] You might want to build old CODE to find a bug, but who wants to go back to old ART? [21:52] awilkins: and that's what it ultilmately boils down to, you cannot even copy the whole history to a single computer [21:53] is there a way to download only a certain revision from a repository so i won't have to download the whole history of the project? [21:53] lousygarua: in bzr? yes [21:53] lousygarua, Yes, you can do a shallow checkout [21:53] lousygarua: you can setup lighweight checkout for example [21:53] ^^ or what he said [21:53] awilkins: lightweigh is the same as shallow? [21:53] I remember talks about doing history horizon but I don't know if that was implemented [21:54] zyga: hmm, ok i will read about shallow/lightweight/whatever thanks [21:54] so that you could see (and have) some history locally [21:54] lousygarua: bzr reconfigure --help [21:54] Lightweight is like SVN - depends on the server [21:54] awilkins: yes [21:54] TBH never really used shallow checkouts but I think they get used on Launchpad to save storage for user forks [21:54] awilkins: and if bzr could just store binaries without processing (and holding them in memory) then bzr would be a perfect VCS for anyone apart from git hardcore users and people loving to rebase (I still do, darn) [21:55] will a lightweight checkout store further revisions locally so it won't have to be SVN entirely? [21:55] lousygarua, No [21:55] awilkins: lp uses stacked branches right? so you get same kind of data saving [21:55] stacked ... I think that's sort of what I may have meant [21:56]