| jam | sttng359: rm -rf .bzr ; bzr init-repo .; bzr svn-import $SVN ? | 00:12 |
|---|---|---|
| jam | a bit overzealous perhaps | 00:12 |
| === r0bby is now known as robbyoconnor | ||
| sttng359 | jam: will existing bzr branches made against my current broken branch still work against a fresh svn import or will it look like a new bazaar branch? | 00:13 |
| === Ursinha is now known as Ursinha-afk | ||
| === Meths_ is now known as Meths | ||
| maxb | sttng359: I think there's a good chance they'll work fine, bzr-svn is supposed to be deterministic and repeatable. I'd say they'd definitely work, but I don't understand how your existing repository could be subtley broken in the way you describe | 01:37 |
| sttng359 | maxb: well, it now looks like every branch I have under that shared repo believes the symlinks should be zero-length files and creating branches outside of that shared repo replicates that, but a fresh checkout using bzr from subversion correctly generates symlinks. | 01:46 |
| sttng359 | I was using that originally to create a couple different test branches without cluttering up subversion, but I may have to recreate them all. | 01:47 |
| === Ursinha-afk is now known as Ursinha | ||
| sttng359 | nope, existing bazaar repos don't recognize my new checkout. | 02:25 |
| sttng359 | maybe it has to do with using a 1.4 subversion server. | 02:26 |
| aaron01 | I'm getting "UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 50: ordinal not in range(128)" when trying to bzr import a tarball. However, if I import the extracted contents of the tarball it works fine. Ideas? | 02:36 |
| spiv | aaron01: sounds like a bug :/ | 02:38 |
| spiv | aaron01: please file a bug report | 02:38 |
| spiv | Hmm. | 02:38 |
| spiv | Off the top of my head the tarball import code assumes all filenames are ascii, but the import from filesystem directory can use the system locale to guess filesystem encoding. | 02:39 |
| spiv | I'm not sure if tarballs store filenames as bytes or in a defined encoding. I suspect bytes... but if so, we could add an option to allow you to explicitly specify the filename encoding. | 02:40 |
| fullermd | I'd be astonished by anything other than bytes, if for no other reason than that tar predates encodings. Well, unless you count EBCDIC, maybe... | 02:43 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| spiv | fullermd: well, there have been occasional extensions to the format IIRC, but yes. | 02:46 |
| === Ursinha is now known as Ursinha-afk | ||
| sttng359 | spiv: from what I understand, the USTAR format for filename is a byte field | 02:53 |
| sttng359 | http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=5&manpath=FreeBSD+8-current | 02:53 |
| sttng359 | does bazaar attempt to convert filenames to UTF-8 for storage? | 02:53 |
| fullermd | Wow, 8-current... | 02:53 |
| spiv | Well, they are unicode in bzr's storage model. The implementation happens to be UTF-8 IIRC, but that detail isn't particularly relevant here. | 03:01 |
| aaron01 | I think it might be helpful if the traceback would be more verbose about what file it is failing on | 03:22 |
| thumper | BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing referenced chk root keys: [StaticTuple('sha1:0fe7e46a367f403f3a2e51af8fa78962cba9f8d3',)] | 03:35 |
| thumper | getting this with 2a merge directives | 03:35 |
| spiv | thumper: hmm | 03:36 |
| thumper | spiv: probably has stacking issues too | 03:37 |
| spiv | thumper: possibly the source repo needs the fix at https://bugs.edge.launchpad.net/bzr/+bug/613698 run on it | 03:37 |
| ubot5 | Launchpad bug 613698 in Bazaar "need reconcile fixer for bug 522637 "missing referenced chk root keys" (affected: 3, heat: 18)" [High,Fix released] | 03:37 |
| spiv | thumper: or possibly there's an issue specific to merge directives | 03:37 |
| thumper | spiv: bug 517126 | 03:39 |
| ubot5 | Launchpad bug 517126 in Launchpad Bazaar Integration "BzrCheckError raised creating a merge proposal (affected: 1, heat: 0)" [High,Triaged] https://launchpad.net/bugs/517126 | 03:39 |
| spiv | thumper: any chance of those "more details" getting filled in? :) | 03:40 |
| spiv | thumper: like which branch? or the contents of the merge directive? | 03:41 |
| thumper | spiv: possibly | 03:45 |
| * spiv -> lunch | 03:49 | |
| === Ursinha-afk is now known as Ursinha | ||
| AfC | Is there a "known" bug about Bazaar not expanding ~ in revision specs? | 04:01 |
| fullermd | bug 138787 | 04:02 |
| ubot5 | Launchpad bug 138787 in Bazaar "revspec paths don't interpret user refs (affected: 0, heat: 0)" [Wishlist,Confirmed] https://launchpad.net/bugs/138787 | 04:02 |
| AfC | fullermd: yeah, that seems like it | 04:10 |
| AfC | so annoying | 04:11 |
| AfC | fullermd: I'm not sure "user refs" is really the right label for it | 04:11 |
| AfC | to me it's "tilda" and "home dir[ectory]" | 04:11 |
| AfC | fullermd: can I suggest | 04:12 |
| AfC | "revision specs don't expand ~ or ~user in paths" | 04:13 |
| AfC | or such? | 04:13 |
| fullermd | Well, ideally I'd suggest "fix released" :p | 04:18 |
| fullermd | 3 years in, it's hard to work up much expectation though. | 04:18 |
| AfC | be nice | 04:23 |
| AfC | fullermd: I commented your bug with our use case; perhaps that'll up its google juice. | 04:30 |
| AfC | Cheers | 04:30 |
| === Ursinha is now known as Jorjao | ||
| === Jorjao is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === r0bby_ is now known as robbyoconnor | ||
| vila | hi all ! | 07:34 |
| === jamesh_ is now known as jamesh | ||
| === zyga_ is now known as zyga | ||
| === Meths_ is now known as Meths | ||
| Kamping_Kaiser | hi all. i had a bzr branch <svn repo> drop out. is there a way to resume it? rerunning bzr branch or bzr up just error, in different ways | 12:34 |
| Kamping_Kaiser | i'd rather not redownload 1.8gb again :( (and still going) | 12:34 |
| maxb | Was the branch a standalone one or into a shared repo? | 12:37 |
| Kamping_Kaiser | standalone | 12:37 |
| maxb | Try running 'bzr heads --dead' in the partial branch | 12:38 |
| Kamping_Kaiser | ok. i'm just making a copy, i'll try it after that :) | 12:40 |
| maxb | Why are you making a copy? | 12:41 |
| Kamping_Kaiser | bzr: ERROR: unknown command "heads" | 12:42 |
| Kamping_Kaiser | because i can't afford to download 1.8 gb again, so i don't want to break a copy | 12:42 |
| maxb | Install bzrtools | 12:44 |
| Kamping_Kaiser | hm, i thought i had it. let me check | 12:44 |
| Kamping_Kaiser | thanks | 12:44 |
| Kamping_Kaiser | i don't have it, branching it atm | 12:46 |
| Kamping_Kaiser | maxb: got it, it removed a commit. do i resume by branching again? | 12:50 |
| maxb | uh? | 12:50 |
| maxb | 'bzr heads --dead' is a query command. it changes nothing | 12:50 |
| Kamping_Kaiser | ah, hehe. the svn commit message contained a coment about removing stuff. guess i confused them | 12:51 |
| maxb | ok, so bzr heads --dead showed one revision, the latest svn revision that actually got transferred | 12:52 |
| maxb | the question now is how to convince bzr to pick up where it left off | 12:53 |
| maxb | Does a .bzr/branch/ directory exist at all? | 12:53 |
| Kamping_Kaiser | no. there is a .bzr/branch-lock dir, but not branch | 12:54 |
| maxb | "bzr branch svnurl ." might work, if not we'll have to get more devious | 12:55 |
| Kamping_Kaiser | sadly, 'bzr: ERROR: Target directory "freeciv" already exists.' | 12:56 |
| maxb | Try adding --use-existing-dir | 12:57 |
| jelmer | 'bzr init && bzr pull <svn-url>' perhaps? | 12:58 |
| jelmer | maxb: I think that will still try to create the .bzr dir | 12:58 |
| Kamping_Kaiser | jelmer: thats trying to re-download it from scratch. | 13:00 |
| Kamping_Kaiser | maxb: that returns 'bzr: ERROR: Already a branch: "freeciv".' | 13:02 |
| Kamping_Kaiser | but trying to pull in the dir i get 'not a branch :/ | 13:02 |
| maxb | I am not so sure, I think jelmer's command would work (run in the directory with the existing .bzr from the first try) | 13:02 |
| Kamping_Kaiser | hm | 13:04 |
| Kamping_Kaiser | wonder whats going on | 13:04 |
| maxb | Any opinions on how long I should wait for potential dissent before copying bzr/proposed to bzr/ppa ? | 13:06 |
| jelmer | maxb: I would be surprised if resume worked in a standalone branch | 13:10 |
| jelmer | maxb: it's a known bug that it doesn't :) | 13:10 |
| jelmer | maxb: Was the pyrex issue fixed? | 13:10 |
| maxb | yes | 13:11 |
| jelmer | in that case I'd say go for it | 13:11 |
| vila | maxb: did we get feedback from people testing bzr/proposed ? | 13:11 |
| jelmer | it's working here, and the only other thing I've heard from others is the pyrex issue | 13:11 |
| maxb | The only active feedback I'm aware of is the report of the pyrex issue | 13:11 |
| maxb | we have tested that the archive as a whole is installable | 13:12 |
| vila | maxb: then I agree with jelmer: go | 13:12 |
| Kamping_Kaiser | hm, perhaps jelmer was right. its only pulling 2000 revisions, so perhaps its pulling the remaining files | 13:15 |
| Kamping_Kaiser | wow... thank you maxb and jelmer, bzr is 'doing stuff' again :) | 13:22 |
| * maxb bites the bullet and executes lp-promote.py bzr/proposed bzr/ppa | 13:24 | |
| bigjools | is the non-compiled extension thing fixed? | 13:24 |
| maxb | yes | 13:25 |
| bigjools | \o/ | 13:26 |
| maxb | whee, look at all the little green cogs :-) | 13:26 |
| * vila notes: always add green cogs | 13:31 | |
| Kamping_Kaiser | hm. bzr appears not to handle its terminal getting resized down very wel :/ (unless its my old version, which it could well be) | 13:36 |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| jml | sad | 13:43 |
| jelmer | jml: ? | 13:46 |
| jml | I just had to type this: | 13:46 |
| jml | bzr resolve src/zope/testing/testrunner/testrunner-ex src/zope/testing/testrunner/testrunner-ex-pp-lib src/zope/testing/testrunner/testrunner-ex-pp-lib/sample4 src/zope/testing/testrunner/testrunner-ex-pp-lib/sample4/products src/zope/testing/testrunner/testrunner-ex-pp-products src/zope/testing/testrunner/testrunner-ex-pp-products/more src/zope/testing/testrunner/testrunner-ex/sample1 src/zope/testing/testrunner/testrunner-ex/sample1/sample11 src/zope/testi | 13:46 |
| jml | r/testrunner-ex/sample1/sample13 src/zope/testing/testrunner/testrunner-ex/sample1/sampletests src/zope/testing/testrunner/testrunner-ex/sample2 src/zope/testing/testrunner/testrunner-ex/sample2/sample21 src/zope/testing/testrunner/testrunner-ex/sample2/sample22 src/zope/testing/testrunner/testrunner-ex/sample2/sample23 src/zope/testing/testrunner/testrunner-ex/sample2/sampletests src/zope/testing/testrunner/testrunner-ex/sample3 src/zope/testing/testrunner/ | 13:46 |
| jml | x/sampletests | 13:46 |
| jelmer | ahh | 13:46 |
| jelmer | I was wondering whether you couldn't find your livejournal window :-P | 13:46 |
| jml | hah hah | 13:47 |
| vila | jml: were there all text conflicts ? | 13:47 |
| vila | jml: a bare 'bzr resolve' is supposed to resolve all "auto solvable" conflicts, but... | 13:48 |
| jml | vila, no text conflicts. | 13:49 |
| jelmer | jml: Or, bzr resolved --all? | 13:49 |
| jml | vila, this is the same old bug that I always complain about | 13:49 |
| vila | jelmer: vade retro satanas: never use that | 13:49 |
| jml | good grief | 13:49 |
| vila | jml: oh, the.pyc files ? | 13:49 |
| jml | I've never heard anyone say that in Latin | 13:49 |
| jml | vila, yes. | 13:49 |
| vila | jml: on top my conflicts TODO list... but ETOOMAYTODOLISTS | 13:50 |
| vila | jml: crystal ball predicting that it may be surface as soon as this week though... | 13:50 |
| vila | jml: oh, in the mean time, I think 'bzr clean-tree --detritus' helps | 14:04 |
| jml | vila, thanks. | 14:04 |
| Kamping_Kaiser | sheesh. bzr can hammer the cpu when it wants. guess its repacking 1.8gb of data though | 14:10 |
| === Ursinha-afk is now known as Ursinha | ||
| kpettit | I'm new to bzr and trying to figure out the best way to do something. I have a main code repository that tends to have different code for each customer. I need to have a main default repository then one for each customer, trying to keep code in sync. 95% of the code stays the same. | 14:40 |
| kpettit | I'm trying to figure out the best way to set this up. So I can have in a directory "main" directory then directories for "customerA" "customerB" etc. | 14:41 |
| maxb | It *sounds* like you want a "main" branch containing customer-agnostic code, each customer is a branch off main, main gets merged into customer branches when needed, but never the reverse | 14:50 |
| maxb | On the occasion that a change on a customer branch is deemed applicable for main it gets cherrypick-merged | 14:51 |
| rubbs | is there any documentation on cherrypick-merges? as kpettit's question is very similar to something we will need here. | 14:52 |
| kpettit | rubbs: I'll see if I can find anythning on that http://wiki.bazaar.canonical.com/CherryPick is the first thing that comes up. | 14:53 |
| rubbs | kpettit: thank you | 14:53 |
| kpettit | For my project it's a web html/css/js thing. Everything is the same except a couple of custom css and js files. I won't have those in the main repository, but I want to have them in each of the individual customer branches. So I want to be able to update customer brances with latest default code and also keep seperate customer css/js custom files in their own repository. | 14:55 |
| maxb | A cherrypick merge is a merge of a specific changeset *not* an entire branch of history. Of particular importance is to note that Bazaar does not track cherrypick merges at all in its own metadata. | 14:56 |
| rubbs | maxb: good to know thank you. | 14:57 |
| rubbs | kpettit: sounds similar to us. | 14:57 |
| kpettit | so there isn't a good default way to do what we're wanting then I guess? | 14:59 |
| kpettit | rubbs: Check this out http://wiki.bazaar.canonical.com/SharedRepositoryTutorial | 15:05 |
| jml | *sigh* | 15:12 |
| jml | Unable to load plugin 'pipeline'. It requested API version (2, 2, 0) of module <module 'bzrlib' from '/usr/lib/python2.6/dist-packages/bzrlib/__init__.pyc'> but the minimum exported version is (2, 1, 0), and the maximum is (2, 1, 1) | 15:12 |
| rubbs | kpettit: yes, I did know about shared repos, and I"m looking into stacked branches. | 15:18 |
| kpettit | that sounds promising. | 15:18 |
| rubbs | I've used bzr before, but always for personal stuff, so I never needed to know about many features, because I never needed them, but I'm having to (re)learn stuff for our company migration to bzr coming in a few months | 15:19 |
| rubbs | I'm trying to come up with a good migration plan | 15:19 |
| kpettit | basically doing the same here. All on SVN right now, but it's painful and doesn't do stuff like this | 15:19 |
| rubbs | right | 15:19 |
| kpettit | If this idea works it'd be nice to apply the same thing to linux config files. Where you have a default and branches for customizaitons and such. | 15:20 |
| rubbs | Right as I was hired, my boss was talking about starting to use branches and thinking about merging down the line. Luckily he listened to me when I told him that multiple merges with svn was awful | 15:20 |
| rubbs | kpettit: you may wish to look at etckeeper | 15:21 |
| rubbs | I'm working on a plan for that oo | 15:21 |
| rubbs | too* | 15:21 |
| rubbs | it can use hg,git, or bzr | 15:21 |
| kpettit | :) I'll do what I can to avoid using cfengine | 15:21 |
| rubbs | heh | 15:21 |
| kpettit | etckeep is good for a individual system. I was thinking for global where we have a default and clone to dozens/hundrends of systems then each of those have their own that can be checked in on a main system as seperate repositories. Makes it easy to clone and develop individual custome systems that way | 15:22 |
| rubbs | right. I know a friend of mine is developing something that might fit your needs, but at this point it's not even up to alpha stage yet. He's going to call it Ranchero. | 15:24 |
| rubbs | I hope he gets something out soon. | 15:24 |
| kpettit | I'll keep my eyes out for it | 15:25 |
| rubbs | it could be a while, just a warning. He goes through spurts. Does a lot of work on it, then just lets it die for a while | 15:28 |
| kpettit | I'm the same way | 15:28 |
| rubbs | Am I correct in thinking that if you have a bound branch, unbind for a while, then rebind, that it will automatically sync revisions? | 15:30 |
| rubbs | at the bind? | 15:30 |
| rubbs | kpettit: not sure if you saw this, but it may help: http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/adv_merging.html | 15:34 |
| kpettit | thanks, reading... | 15:36 |
| kpettit | I got etckeeper as well. The docs say it uses git by default but on ubuntu the default etckeeper package uses bzr which is cool with me | 15:36 |
| rubbs | same here, you also use ubuntu for prod servers? | 15:37 |
| kpettit | yes | 15:37 |
| kpettit | I'm using rackspacecloud and mainly ubuntu 10.04 images | 15:38 |
| kpettit | we do alot of windows stuff, but I try to ignore that as much as possible | 15:38 |
| rubbs | know that feeling well ;) | 15:39 |
| maxb | jml: hmm? | 15:41 |
| jml | maxb, I just had to add a ppa, no big deal, just another hurdle. | 15:41 |
| maxb | jml: ok, but what combination of ppas did you have that produced the error in the first place? | 15:42 |
| jml | maxb, Lucid & the pipeline branch. | 15:42 |
| jam | hi vila, thanks for the reviews | 15:43 |
| maxb | Oh, I see | 15:43 |
| maxb | jml: there's a lp:bzr-pipeline/2.1 | 15:43 |
| jml | maxb, too late now :) | 15:43 |
| maxb | rubbs, kpettit: shared repositories and stacked branches are all about avoiding wasted diskspace - they have no bearing on your development workflow | 15:43 |
| vila | hi jam | 15:43 |
| kpettit | maxb: got ya. Any suggestions? | 15:44 |
| jam | vila: 'saw' doesn't seem to have python-testtools installed. Did I do something wrong? | 15:44 |
| vila | jam: hmm, no, I use a private branch, let me check | 15:44 |
| rubbs | maxb: right, I knew that. I'm the systems guy here, so I have to keep that in mind too, and in a way it will impact workflow as permissions to the central server will impact if I need to do stacked vs shared. | 15:44 |
| maxb | kpettit: Is there any reason you want your customer specific stuff in a separate *repository*? What did you think of my initial suggesting regarding branches? | 15:45 |
| maxb | rubbs: Ah, yes, that's a factor. I'd be interested to know what you end up with, I'm attempting to set up a fledgling bzr environment at my workplace too, in the hopes of wooing them away from svn | 15:45 |
| rubbs | kpettit: you could keep things in a shared repo, and have separate branches for each client/customer. | 15:45 |
| jam | vila: I set something up using PYTHONPATH, but that is a bit clumsy | 15:45 |
| vila | jam: installing testtools and subunit | 15:46 |
| jam | vila: thansk | 15:46 |
| jam | thanks | 15:46 |
| rubbs | maxb: I'm still working on ideas, but if I come up with one, or at least come up with a preliminary plan I'll spam the mailing list. Maybe I can get some improvements on the ideas I have ;) | 15:46 |
| kpettit | maxb: you were right on what I want. The main branch I want copied to child brances. They child brances will have files that aren't in the main branch that need to be versioned but they will not need to commit from the child to main branch | 15:46 |
| maxb | Oh, whilst I have testtools and subunit-knowing folks here: should we be updating the ~bzr ppa to the latest upstream of those? | 15:46 |
| vila | damn, babune's xp slave is hosed :-/ | 15:47 |
| jam | maxb: If you are willing to do the work, it would be great to get the updates :) | 15:48 |
| rubbs | kpettit: yeah, I would suggest a shared repo for you then, (or stacked if you want to limit commit access to certain branches) and just merge from the main, into the customer branches. | 15:48 |
| kpettit | maxb, rubbs: So I'm trying to figure out the best way to do that, shared repo's seem promosing but I'm still learning. | 15:48 |
| rubbs | LP uses stacked branches IIRC. | 15:48 |
| maxb | jam: work? what work? dget python-testtools/sid; for i in hardy jaunty karmic lucid; do bzrppa-backport -s -u bzr/proposed -D $i *.dsc; done | 15:49 |
| maxb | I really need to stick my handy scripts somewhere :-) | 15:49 |
| kpettit | rubbs: that sounds like the right way to go. I've just setup some test for it so I'm going to play around and see if ti works like I'm expecting. | 15:49 |
| maxb | kpettit: the thing you need to understand is that shared repositories are merely a disk space / network io optimization. They don't affect the design of your workflow, really | 15:50 |
| kpettit | got ya. But I can merge from a parent repository to a child one and not overwrite or mess up and files that child has that the parent doesn't? | 15:51 |
| rubbs | kpettit: what maxb just said, also adding that each branch will still be insular, by which I mean that even though you will be storing revisions in the same place, it will not automatically add revisions to branches you don't want them in | 15:51 |
| rubbs | kpettit: I think you're confusing branches and repositories. | 15:52 |
| kpettit | I might be | 15:52 |
| kpettit | <-- new at this | 15:52 |
| rubbs | branches are just an "order of revisions" in a sort of way. repos are just a place where revisions are stored. | 15:52 |
| maxb | repository == an on disk store of revisions, nothing more. branch == a pointer to a revision that is tip of the branch (and implicitly all its ancestors) | 15:52 |
| rubbs | by default (stand alone branch without a shared repo) a branch is it's own repository because the only revisions needed in that repo are the same as the ones on the branch. | 15:53 |
| rubbs | in a shared repository, you can have many different branches. | 15:53 |
| rubbs | revisions that are the same between branches are not duplicated. | 15:53 |
| maxb | s/ a branch is it's own repository / both branch and repository are co-located in the same .bzr directory / | 15:53 |
| rubbs | so if branch A has revisions 1,2,3 and branch B has 1,2,4 the shared repo will contain 1,2,3,4 | 15:54 |
| rubbs | thanks for that clarification maxb | 15:54 |
| maxb | For clarity's sake, it's best to use a,b,c as placeholder names for revisions, since the integers can be confused with bzr revnos | 15:55 |
| rubbs | ah, I will do that in the future | 15:56 |
| kpettit | so if my child directories I want them to all keep a up to date copy of main set of code. but I need them to have files that will never be in the main set of code and keep version info. So if my parent is a "repository" are my childs of this branches or other repositories sense they will never commit back to the parent? | 15:57 |
| rubbs | best to think about repos as a bin to store all revisions in it. Each branch is just a list of revisions and their order. So in your case, you would make a shared repo, then put your "trunk" or "main" in it. Then you would make a branch, also in the same repo, for customerA. | 16:05 |
| rubbs | then when you wanted to get changes from the trunk into customerA you just do a "bzr merge trunk" while inside the customerA branch. | 16:06 |
| kpettit | got ya. that's what I'm trying now. thanks | 16:06 |
| rubbs | This will pull changes from trunk in, but will NOT put changes from customerA into trunk. | 16:06 |
| rbriggsatuiowa | is there anyway to pass a plugin directory to bzr? | 16:07 |
| vila | rbriggsatuiowa: there are several even :) see 'bzr help env-variables' | 16:09 |
| vila | rbriggsatuiowa: depending on your need you will use BZR_PLUGIN_PATH or BZR_PLUGINS_AT | 16:10 |
| rbriggsatuiowa | vila: bawesome - thanks | 16:13 |
| === Ursinha is now known as Ursinha-lunch | ||
| rubbs | is there any way to make a stacked-repo? By which I mean, if I want to have the trunk with read only permissions, can I create a shared repo for each user that is stacked off that main trunk? | 16:21 |
| rubbs | I'm looking for a roll your own poormans LP basically | 16:21 |
| jam | rubbs: stacking is done at the 'branch' level, not the repo level | 16:26 |
| jml | I'm trying to use pipelines to split up a big branch that I've already done a fair bit of work on. | 16:26 |
| jam | you *can* set up a default stacking policy | 16:26 |
| jml | never really used pipes in anger before | 16:26 |
| rubbs | jam: is there any docs on how to do that? | 16:27 |
| jam | jml: This is how I did it with regular branches, you could probably do something similar w/ pipelines | 16:27 |
| jam | http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html | 16:27 |
| jam | I've never used bzr-pipeline myself | 16:27 |
| jml | I guess if this were a loom, I'd make a trunk thread... | 16:27 |
| jml | jam: thanks. | 16:28 |
| jam | rubbs: not that I specifically know of, but I'm poking around looking now | 16:28 |
| jam | jml: the key is abuse of 'bzr revert' and 'bzr merge' to maintain history, while still splitting out the content into simplified diffs | 16:28 |
| rubbs | jam: thanks, I'll keep an eye out for it too. I'm currently re-digesting the official docs | 16:29 |
| jml | jam: :) | 16:29 |
| vila | pfew, backups are a blessing... | 16:29 |
| jam | rubbs: the file is .bzr/control.conf | 16:29 |
| rubbs | jam: ah thanks. I'll take a look at it | 16:29 |
| jam | you can set 'default_stack_on = ...' | 16:30 |
| rubbs | is this per client? or on the server side | 16:30 |
| jam | rubbs: on the server side | 16:30 |
| rubbs | perfect. Thank you. | 16:30 |
| jam | basically, when creating a new branch we look up for a containing repo or just a .bzr directory | 16:31 |
| jam | if we find one with that set, then we'll create a stacked branch | 16:31 |
| jam | you probably could create shared repos for each user | 16:31 |
| jam | and just put "echo ../central-repo > .bzr/control.conf" | 16:31 |
| jam | obviously, you'll want to test it :) | 16:31 |
| jam | for the full commands: | 16:31 |
| rubbs | right. I have no intentions of putting this in place without some testing ;) | 16:32 |
| jam | bzr init-repo --no-trees central; bzr init-repo --no-trees user1; echo "../central" > user1/.bzr/control.conf | 16:32 |
| jam | although... I think a branch has to be stacked on another branch | 16:32 |
| jam | so probably | 16:32 |
| jam | echo "../central/trunk" | 16:32 |
| rubbs | great thanks, I'm copying that out for reference thank you. | 16:33 |
| jam | though you may also be able to do: | 16:33 |
| jam | echo -e "default_stack_on = ../central/trunk\ndefault_stack_on:policy=appendpath" depending on how you would use it | 16:33 |
| rubbs | sounds good. I have some reading to do now ;) | 16:34 |
| jam | rubbs: I don't know about a lot of reading, vs just experimenting :) | 16:39 |
| rubbs | haha, true. I'm looking into several things at once. Trying to build up a migration plan. I still have to teach all the devs how to use bzr as well, so i'm reading all the docs so I can try to choose the best workflow to teach to them. | 16:40 |
| rubbs | I was told not to give them too many choices on workflows or they are going to run into trouble | 16:40 |
| jam | rubbs: good advice | 16:41 |
| jam | One thing you can do is start of with the most simplistic model | 16:41 |
| jam | and they can adapt to something better as they are able | 16:41 |
| jam | I certainly have *my* preferred model, though | 16:41 |
| rubbs | right. I was thinking a happy medium between function and ease is bound branches, with their own server space. That way I can back it all up easy and they can have local stuff if needed. | 16:42 |
| rubbs | and I can help them along if they have any "customizations" to their workflow | 16:43 |
| vila | windows hates me, I swear, it's not the opposite | 16:43 |
| rubbs | I'm in the weird position of going from dev to sysadmin, so I actually know bzr from the dev side fairly well. It's all this being a repo admin that's new to me. ;) | 16:43 |
| jam | rubbs: :), we'll try to ease your pain | 16:44 |
| jam | vila: I still love you | 16:44 |
| jam | what's going on with the XP vm? | 16:44 |
| jam | bbiab | 16:45 |
| vila | jam: no idea, I restored a first backup (known to work), it was broken too, then I went for an older one and it works | 16:45 |
| vila | now, there was a vbox upgrade since then and at least one windows upgrade | 16:45 |
| vila | but failing to login makes it hard to debug anything :-/ | 16:46 |
| vila | so I upgraded the vbox extensions on the older backup and I will cross my fingers when the xp update triggers... | 16:46 |
| jml | "bzr add-pipe --before foo" seems to make "foo" equivalent to the parent branch | 16:47 |
| === beuno is now known as beuno-lunch | ||
| jml | is "bzr merge -i" different from "bzr merge; bzr shelve" in any way other than negating the "y/n" choice? | 16:51 |
| vila | jml: that would greatly simplify the implementation :-P | 16:53 |
| vila | jml: sorry, no idea | 16:53 |
| jml | vila, ok. related question: how can I tell if the thing I'm about to commit looks like a merge to bzr? | 16:55 |
| vila | bzr st will mention pending merges | 16:56 |
| jml | vila, thanks :) | 16:57 |
| jml | so the answer is "yes" | 16:57 |
| jml | "bzr merge -i" forgets the merge | 16:57 |
| vila | 8-( | 16:57 |
| vila | oh, because it becomes a cherrypick probably | 16:58 |
| jml | yeah. | 16:58 |
| vila | jml: you're rewriting a too-big patch ? | 16:59 |
| jml | vila, indeed I am. | 16:59 |
| vila | I wish we had better tools for that... | 16:59 |
| jml | vila, not as much as I do right now :) | 16:59 |
| vila | jml: almost, I was finishing one yesterday (from a branch to a loom but interrupted during 3 weeks) | 17:00 |
| vila | the most annoying bit is that I always find a better way while rewriting those losing a base to compare... | 17:00 |
| vila | not that I can imagine tools to help here... | 17:01 |
| vila | jml: in the end, one command I often use anyway is: 'bzr merge --preview <old_result>' | 17:01 |
| vila | which set submit_branch in branch.conf unfortunately... | 17:02 |
| jml | I wish I knew how to stop receiving bzr review mail. | 17:14 |
| mgz | hey vila, do you have a branch up anywhere with all your leak bits that I can test locally? | 17:21 |
| vila | mgz: oh, I have several, I just put them up for review :) | 17:24 |
| mgz | I saw that, just wondering if for-babune or similar still has them all rolled up in one branch | 17:25 |
| vila | mgz: but lp:~vila/bzr/leaking-tests should contain everything | 17:25 |
| mgz | ta. | 17:25 |
| jam | jml: you're probably subscribed to the bzr.dev branch directly? | 17:26 |
| vila | mgz: there may still be some rough edges, but I'd like to get them landed first as they have been sitting there for far too long | 17:26 |
| jml | jam: no, not directly | 17:26 |
| jam | jml: are you in the bzr-core team? | 17:27 |
| jml | jam: I'm a member of bzr-core via canonical-bazaar | 17:27 |
| jml | jam: I wish to remain a member of canonical-bazaar. | 17:27 |
| jam | jml: then figure out how to design launchpad subscriptions so you can explicitly opt-out of stuff, I would like that ability myself :) | 17:30 |
| jam | or just set up your >/dev/null procmail filter | 17:30 |
| mgz | can you filter based on the message at the end? | 17:30 |
| mgz | I think merge proposals have that right, though bugs don't | 17:31 |
| jam | mgz: there are some launchpad specific headers you are supposed to use, but I haven't really figured them out | 17:31 |
| jam | like: | 17:31 |
| jam | X-Launchpad-Message-Rationale: Reviewer | 17:31 |
| jam | X-Launchpad-Project: bzr | 17:31 |
| mgz | yup, same mechanism. | 17:31 |
| jam | X-Launchpad-Notification-Type: code-review | 17:31 |
| jam | but there isn't one defining the *target* of the merge, which is weird | 17:31 |
| mgz | gmail just doesn't let me filter on anything but a few common headers | 17:32 |
| jam | it also doesn't tell you that "you are requested to review" because the group you are in was requested | 17:32 |
| jam | versus a direct request of me | 17:32 |
| jam | which is something I should file a bug on | 17:32 |
| mgz | ah, that's like the bugs bug then. | 17:32 |
| SpamapS | Somebody needs to extend IMAP to allow server side filters to be managed directly through IMAP. | 17:32 |
| jam | SpamapS: sieveshell | 17:32 |
| jml | fwiw, we're doing this atm: https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications | 17:33 |
| jam | from the Cyrus suite | 17:33 |
| mgz | the bugs header doesn't tell you if you're directly subscribed to the bug if you're a member of a group that'd get email anyway | 17:33 |
| SpamapS | there are tons of web interfaces | 17:33 |
| SpamapS | But its hard to get imap admins to enable them. ;) | 17:33 |
| mgz | merge proposals at least say something different when it's my merge proposal or one I'm reviewing | 17:34 |
| * SpamapS puts it on his todo list for crazy ideas. :) | 17:34 | |
| jml | jam: btw, thanks for the heads up re testtools tags. | 17:35 |
| jam | jml: np, I was trying to figure out what versions I had from 'bzr log' | 17:36 |
| jml | jam: I hate having to reinvent release procedures for every single project :\ | 17:36 |
| jam | jml: well, there are some common pieces. I know 'bzr-builddeb' hooks into the tag code so that "bzr tag" can take a default tag name of the last entry in debian/changelog | 17:37 |
| jam | It would be interesting to have a "bzr release" function, but so often there is a lot more than just 'export + tag" | 17:37 |
| jam | (changing the version strings, etc, etc) | 17:37 |
| jml | hooks, perhaps | 17:37 |
| jam | jml: yeah, there have certainly been hooks requested for 'bzr export' | 17:38 |
| jml | Twisted has a change-versions script used for its release | 17:38 |
| === Ursinha-lunch is now known as Ursinha | ||
| jml | (as well as build-news, which takes file-per-news-entry and turns it into an actual news file) | 17:38 |
| jml | I also never know which revision to tag. | 17:39 |
| jam | jml: approximate is better than nothing :) | 17:41 |
| jml | yeah, I know. | 17:42 |
| jml | but uncertainty is a paralytic. | 17:42 |
| jam | losa ping (about pqm) | 17:44 |
| jml | how do you undo "bzr tag" | 17:45 |
| mthaddon | jam: hi | 17:45 |
| jam | mthaddon: hey, I submitted some stuff to pqm yesterday, which should have failed, but I didn't get a failure email | 17:45 |
| dash | jml: bzr tag --delete? | 17:45 |
| jam | I can submit it again today, but I figured I'd try to figure out what went wrong first | 17:45 |
| jam | dash: yeah, but --delete doesn't propagate well now | 17:46 |
| jam | (for now) | 17:46 |
| jml | dash, thanks. I was looking for "untag" | 17:46 |
| bigjools | heh, bzr tag help didn't do what I expected :) | 17:46 |
| mthaddon | jam: but it didn't succeed either? what time? | 17:46 |
| jam | mthaddon: yesterday about 5 hours from now | 17:46 |
| jam | ~2200 utc | 17:46 |
| mthaddon | it's a little hard to tell - there's one at 21:39, one at 22:36 | 17:49 |
| jam | mthaddon: the latter one is the one I care about | 17:49 |
| mthaddon | jam: https://pastebin.canonical.com/36209/ | 17:49 |
| kpettit | I'm wanting to make bzr our standard VCS, but I have some .NET developers that use VisualStudio. Are there any plugins and such that work with VisualStudio? There was one on the 3rdParty page but it says discontinued and it's for a older version. | 17:50 |
| jam | mthaddon: I see some warnings, but no real indications of anything, can you try the other? | 17:50 |
| mthaddon | jam: https://pastebin.canonical.com/36210/ | 17:51 |
| jam | mthaddon: well, that does help: smtplib.SMTPSenderRefused: (552, '5.3.4 Message size exceeds fixed limit', 'pqm@bazaar-vcs.org') | 17:51 |
| jam | though I don't know how to make it smaller... | 17:52 |
| jam | mthaddon: ok, I'm submitting again now. Is there any way to grab the content of the output email in case it fails again? | 17:53 |
| jam | (I think my smtp host restricts to <10MB, but that should be plenty for these emails) | 17:53 |
| mthaddon | only way would be to send it to a logfile instead of emailing it | 17:53 |
| mthaddon | but I think that's something PQM is doing rather than the cronjob that calls PQM if I recall correctly | 17:54 |
| === beuno-lunch is now known as beuno | ||
| rubbs | kpettit: not that I know of, I'm looking for something like that too | 18:21 |
| kpettit | rubbs: I'll let you know if I find anything. Gotta make the Windows guys happy :) | 18:21 |
| rubbs | kpettit: ditto ;) | 18:22 |
| kpettit | I'm happy with my bzr setup now and moved it to a production server. The branches work, but the share repository seems to cause issue. | 18:48 |
| kpettit | When I go to base directory and do bzr status I get "No Working Tree" and it's looking for a .bzr/checkout | 18:48 |
| kpettit | I can go to the individual branches and bzr status works fine there. Not sure what to do, the origional one I copied from still works fine | 18:49 |
| beuno | kpettit, the shared repo does not have a working tree | 18:49 |
| beuno | status is for working trees | 18:49 |
| kpettit | ah ok. | 18:50 |
| kpettit | sorry | 18:50 |
| beuno | no need to apologize :) | 18:52 |
| beuno | you can use "bzr info" if you want to be assured everything is fine | 18:52 |
| kpettit | ah wonderful. thanks. Just wanted to get my "it's ok" from it | 18:53 |
| kpettit | trying to see if trac works with it now | 18:53 |
| kpettit | woo hoo trac was cake to setup. love it | 18:57 |
| === gnomefreak76 is now known as gnomefreak | ||
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| === radoe_ is now known as radoe | ||
| yann2 | hi | 20:34 |
| maxb | hi | 20:37 |
| yann2 | is using paths like bzr+ssh supposed to work with bazaar explorer on windows? it seems to get very confused about it, works for some things, but sometimes it tries c:/bzr+ssh:// etc and fails | 20:39 |
| * maxb knows nothing about windows | 20:46 | |
| maxb | james_w: Hi. lp:bzr-builder contains a plugins/builder symlink actually in the branch. Is it something you particularly want there? Because it confuses bzr multi-pull horribly. | 20:49 |
| james_w | maxb: it can go away once we can use BZR_PLUGINS_AT to run the tests. mutli-pull should be fixed as well of course :-) | 21:29 |
| Kaspi | hello | 22:30 |
| Kaspi | is there a way of using bazaar as subversion for beginers? I don't understand why I need to "commit" and then "send" or "push" or "merge" to make changes in the central branch for each dev | 22:52 |
| Kaspi | i was following this tutorial: http://doc.bazaar.canonical.com/bzr.2.1/en/mini-tutorial/index.html but I got really confused after getting several errors | 22:53 |
| Kaspi | why the "commit" doesn't really commit changes? | 22:55 |
| maxb | Commit does commit changes | 23:00 |
| maxb | I suggest you move up from the mini-tutorial to the full tutorial, and especially read the "How DVCS is different" section | 23:01 |
| jelmer | 'morning maxb | 23:02 |
| maxb | evening here :-) | 23:02 |
| jelmer | oh, here as well actually :-) | 23:02 |
| jelmer | maxb, Whereabouts are you based? | 23:02 |
| maxb | London | 23:03 |
| jelmer | I thought you were in Australasia for some reason. | 23:03 |
| maxb | haha, no | 23:03 |
| maxb | I love my ridiculously low ping time to launchpad :-) | 23:03 |
| maxb | ~ 5 ms | 23:03 |
| sttng359 | hello | 23:09 |
| sttng359 | I am having issues with files loosing their symlink status after certain operations | 23:10 |
| sttng359 | This branch was imported originally with bzr-svn | 23:10 |
| sttng359 | When I first did my checkout from svn, the files were symlinks | 23:11 |
| sttng359 | I think did a remove-tree, and cloned the branch within a shared repo for actual work. | 23:11 |
| sttng359 | I have since noticed that those symlinks are now zero-length files | 23:12 |
| sttng359 | I did a checkout of the original branch and they are zero-lenth files as well. | 23:12 |
| maxb | This sounds nigh-impossible to debug unless there's a way someone can reproduce the failure mode locally... is the svn public? | 23:14 |
| sttng359 | maxb: no, but I can create a public svn repo for testing | 23:15 |
| maxb | I guess we should first eliminate the obvious... there's no possibility of a filesystem that does not support symlinks being involved? | 23:16 |
| sttng359 | nope, only a local Ext3 filesystem. | 23:18 |
| maxb | hmm | 23:18 |
| sttng359 | This time I even used a file:// URL for subversion instead of https:// | 23:18 |
| sttng359 | is there a possibility bzr-svn is creating a symlink, but not marking it as a symlink in the repo? | 23:19 |
| maxb | jelmer: still around? | 23:19 |
| jelmer | sttng359, yes, there has been a bug like that in older versions of bzr-svn | 23:19 |
| jelmer | sttng359, but in that case the issue would turn up in the original import | 23:20 |
| === Meths_ is now known as Meths | ||
| * maxb is attempting to comprehend the purpose of loom's record command.... is it just so the overall loom state can be pushed and pulled? | 23:21 | |
| Kaspi | maxb: hmm a better one | 23:25 |
| sttng359 | jelmer: is bzr-svn-1.0.2 too old by any chance? | 23:27 |
| jelmer | sttng359, don't know, sorry | 23:27 |
| maxb | 1.0.3 is out, you might as well use it | 23:27 |
| sttng359 | is there any difference between using co and a svn+https:// or file:// URL vs. svn-import? | 23:27 |
| jelmer | sttng359: I *think* it should be new enough | 23:28 |
| jelmer | sttng359, no, that doesn't matter | 23:28 |
| sttng359 | It's only 1 version old | 23:28 |
| maxb | the difference between co and svn-import is whether you get one branch or all of them | 23:28 |
| Kaspi | maxb: is possible that bzr would "remember" password to a FTP or SFTP location? | 23:30 |
| maxb | Try this: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/authentication-help.html | 23:31 |
| maxb | Basically you write the user and password into ~/.bazaar/authentication.conf | 23:31 |
| Kaspi | maxb: yeah.. thank you | 23:33 |
| yann2 | are there any nice web frontends to bazaar, that allow to browse versions and diffs - and if possible do not require a db? | 23:35 |
| maxb | there is loggerhead, which is what you see on launchpad.net | 23:35 |
| maxb | http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/changes | 23:36 |
| yann2 | any demo somewhere? | 23:37 |
| maxb | the url I just gave | 23:37 |
| yann2 | oh right :) | 23:37 |
| yann2 | I'll give it a try thanks | 23:37 |
| maxb | I have yet to find a *good* web interface for browsing a collection of multiple bzr branches | 23:38 |
| thumper | jam: ping | 23:39 |
| yann2 | this one does only one branch? I'll see what I can do | 23:39 |
| yann2 | fairly new to VCS and am trying to set a whole dev system up :) | 23:39 |
| jam | thumper: I'm not really around now, I expect to go at any time for family stuff, but if its quick I'll help :) | 23:42 |
| thumper | jam: can I get you to email me tomorrow morning your time about the branch revision work that you started and where it is at now? | 23:42 |
| jam | thumper: basically hasn't progressed anywhere. We got the BranchRevision object to be Stormified (so that you can use a multi-column primary key), but haven't tracked that through into actually removing the columns | 23:44 |
| jam | also, I haven't done the sit-and-think-about-it to get something like bzr-history-db for your use cases | 23:45 |
| jam | most of which want a fast revision_id => branches mapping | 23:45 |
| jam | which isn't what bzr-history-db is about (yet) | 23:45 |
| * thumper nods | 23:46 | |
| sttng359 | ok, I think I have a better idea what's going on here. | 23:47 |
| sttng359 | Not all symlinks are being reset in bazaar, only those with a bad history. | 23:47 |
| sttng359 | TortoiseSVN on Windows does not deal with symlinks properly, instead it creates a text file with the contents of the link, and on check-in, drops the svn:special property, even if that file was not modified. | 23:49 |
| sttng359 | A user in the past did a checkout of a portion of the tree and later a commit. | 23:49 |
| sttng359 | I since had to delete those symlinks and re-add them as symlinks. | 23:50 |
| sttng359 | Other symlinks outside of the portion that the Windows user checked out are still symlinks. | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!