asaclifeless: fyi, http://paste.ubuntu.com/3387/00:09
asaclifeless: local operations on that tree is now working well performance wise btw. thanks00:10
lifelessasac: cool00:13
asaclifeless: yeah ... but 25min is too long ... the 81M should be much faster. but maybe that lp00:16
=== mw is now known as mw|out
asaclifeless: wow ... i tried https://code. ... it just took 6 minutes. thats fair. so maybe it was indeed lp ssh server slowness00:18
lifelessasac: its in pack format now ?00:19
asaci used just bzr init with 1.1.0.dev.000:19
asacbzr info says: Standalone tree (format: pack-0.92)00:20
ubotuNew bug: #181391 in bzr "model 1 to 2 conversion breaks revision sha1 validator" [High,Triaged] https://launchpad.net/bugs/18139100:51
lifelesspoolie: I'm off to buy groceries bbiab.01:30
=== cprov is now known as cprov-ZzZ
jelmerlifeless: Now that PPA supports Dapper, Edgy and Feisty, do you have any plans to move the bazaar-vcs.org debian repo to PPA or would you rather keep it separate because of the signing?02:02
pooliejelmer, i'd kind of like to do it in PPA, i think Robert has unresolved objections02:38
pooliemainly that it's not signed, and cannot build on non-intel architectures (which we don't build now anyhow)02:38
poolieoh, also that there's more latency02:38
bignose_I'm trying to 'rm' a file, and 'mv' another file into its place, as part of a single revision03:33
=== bignose_ is now known as bignose
bignose'bzr rm foo'03:33
bignose'bzr mv bar foo'03:33
bignoseresult: "Could not move bar => foo: foo is already versioned."03:34
bignosebut this is conceptually part of a single change. how can I achieve it without separate commits?03:34
spivbignose: works for me.  What version of bzr do you have?03:36
bignoseBazaar (bzr) 1.0.003:37
spivHmm.  I'm using bzr.dev.03:38
spivbignose: works for me with 0.92 too.03:39
bignoseahhh. I'm in a 'bzr shell'03:40
spivbignose: I see this result: http://rafb.net/p/rnDFwP86.html03:40
bignoseexperimentation shows that 'rm' in the shell **doesn't* invoke 'bzr rm'03:40
bignosewhy would that be?03:41
spivbignose: I think "rm" in the shell executes /usr/bin/rm03:41
spiv(or rather /bin/rm...)03:42
spivbignose: it appears "bzr shell" from bzrtools special cases "rm" and "ls" to always use the system version rather than the bzr command.03:43
bignosespiv: thanks. it's annoying, but I can at least see the reason now.03:44
lifelesspoolie: and that we can't poke and tweak it; its behind an automation barrier as opposed to an admin barrier04:15
=== asac_ is now known as asac
mlhpoolie: would it be fair to say that you are the Designer of bazaar?07:27
mlhbecause there's a message on http://thyrsus.com/lists/uvc-reviewers/2008-January somewhere07:33
mlhthat says that 'the designer of bzr was an Arch hacker' which is not really true as far as I know07:33
mlhI'll find the exact url if you like07:34
mlhlifeless: ^ also07:34
lifelessis that a leading question?07:34
lifelessuvc ?07:35
lifelessanyhow, thats bogus07:35
mlher maybe07:35
mlhesr's attempt to write a guide and history to version control systems07:35
lifelessmartin architected the overall initial design 2 years ago based on a review of arch/monotone/svn/cvs/some others07:35
mlhbogus - that's what I though07:35
mlhthat's what I understood.  and esr should have been able to go over the sourcefrog blogs perfectly well on his own07:36
lifelessbzr's current design only has a little resemblance to that first design, though the design -goals- have not changed.07:36
mlhnod also07:36
lifelessI was an Arch hacker; and I've had some influence on the design, as have Aaron Bentley and many others07:37
mlhyes, and that's where I persume they get tat imperssion07:37
lifelessI would label Martin Architect, not designer, to me it carries a less solitary-load-bearing-sole-responsibility thing07:37
mlhbut he has an obligation to write history acrruately if at all07:37
mlhyeah architect, .. that's why I wrote Designer with a captial D :-)07:38
mlhperhaps it's a nice goal to draw a narrative out of the histoy, but he(inevitably?) over simplifies07:39
mlhHere's the link: http://thyrsus.com/lists/uvc-reviewers/2008-January/000023.html07:46
mlhquote: bzr -- Designed and written by a former Arch hacker.07:46
mlh he's been taken to task for the other bits in that message but not that one07:47
mlhI can folloow up if you don't care too07:47
AfCbzr has been written by a great many people.07:47
mlhoh I'mm well aware of the history of bzr.07:48
mlhreading esr and -t's messages gived me indigestion07:49
* mlh feels woozy - decides to go home07:50
AfCGlancing at the commit history, it doesn't look like that will be a very interesting book. I'm sure it will be widely read, though {sigh}.07:50
dleeFwiw, I think bzr's history a bit interesting but its future far more so. :)  I may seem a bit overzealous, but I expect it will become king among the free VCS out there at some point.08:03
dleeIt just doesn't get in my way very often at all...08:03
fullermdI sure would like to insert it into a place or two...08:21
dleefullermd: Was that to me or AfC?08:35
lifelessmlh: please follow up08:38
fullermdTo your general thrust (though I rather doubt bzr will become king, or that there will be a king)08:44
Lo-lan-doHi all08:56
Lo-lan-doWhat's the current recommended storage format for bzr if I want to use bzr-svn?08:57
dleeHehehe, well, I hesitated looking for a better word than "king," but I mean in the sense of being most widely preferred.08:57
fullermdYeah, I'm just not sure there will be one.  I'm pretty much certain there will never again be a VCS that owned the market like CVS did.  I'm not sure there will ever be any majority system.08:59
fogHi. I have a problem with bzr but maybe it is just me (and not bzr)09:08
fogfrom last time I used it the "bundle" command disappeared and "send" doesn't produce anything.09:09
mwhudsoni think you can say send -o output.bundle can't you?09:09
* mwhudson checks09:09
fogI'd like to get the last n revisions and bundle them but while "patch -rX" works, "send -rX" doesn't produce anything09:09
fogjust a header09:09
mwhudsonfog: yes, looks like it09:10
fogmwhudson: yes, I tried send but it outputs just the header.09:10
fogI can use diff (sorry, not patch) and produce a meaningful output but I can't put the same diff in a bundle using send.09:11
fogso, how can I use send to produce the "same content" of diff, but in a bundle?09:14
jameshfog: try "bzr send -r X..-1"09:16
jameshthat will bundle the sequence of revisions from X to -1 (the head revision)09:17
jameshor "bzr bundle -r X..-1" even09:17
fogah.. it works.09:19
fogjamesh: the help text about "-r" says to see revisionspec but revisionspec doesn't talk about "..". should't be better if the help explained that some commands take a range of revisions?09:21
fogjamesh: btw, many thanks.09:21
astrawHi. A while ago, I exported my svn repo and used it as the start of a bzr branch, which I've been committing to. Now I want my svn history.09:22
jameshfog: that sounds like a bug09:22
astrawI have successfully created a new bzr branch with all the svn history. How do I take all the revisions from my original bzr branch and append them to my new bzr branch?09:22
jameshastraw: perhaps try the bzr rebase plugin09:23
jameshit will let you apply a sequence of changes to an unrelated branch09:24
astrawjamesh - thanks, that looks like what i want. i knew there had to be a way.09:24
astrawhmm, rebase is giving me: "bzr: ERROR: Repository KnitRepository('file:///repo-with-recent-changes/.bzr/repository/') is not compatible with repository KnitRepository('file:///repo-newly-created-with-svn-history/.bzr/repository/')"09:35
astrawThis is the outcome of running: bzr rebase --dry-run /repo-newly-created-with-svn-history09:36
astrawfrom the repo-with-recent-changes branch09:36
jameshastraw: what are the types of the two branches as reported by "bzr info"?09:39
astrawjamesh: Standalone tree (format: dirstate) and Standalone tree (format: rich-root)09:40
astraw(repo-newly-created-with-svn-history is the rich-root)09:41
jameshso the dirstate one is the old branch with your changes in it?09:41
fogmwhudson, jamesh: thank you for the help. cu.09:41
dleefog/jamesh: 'bzr help revisionspec' includes an example using '..' but, as fog says, does not actually discuss '..' directly.09:42
jameshastraw: I'd take a copy of the branch and run "bzr upgrade --format=rich-root" on it.09:42
fogdlee: yes, I've seen the example after jamesh told me about .. :)09:42
jameshastraw: use the copy as the source for the rebase09:42
fogdlee: but I missed it the first time. it is buried quite deep.09:42
Lo-lan-doIs rich-root-pack still considered experimental in 1.1?09:43
foganyway go to go. thanks again.09:43
datoLo-lan-do: seems to be, still. a patch went in recently to mark pack-0.92 as non-experimental (!!!), so...09:46
datoso it should be marked as non-experimental as well, given that rich-root is not experimental itself09:47
datoLo-lan-do: thanks for bringing up09:47
Lo-lan-doI'm about to start a new repository, and since it's going to interact with SVN, I'm pondering about the best format.09:48
Lo-lan-doA bzr branch from the SVN repo gives me a rich-root format, currently (1.0)09:49
Lo-lan-doI'd like to switch to a packed format, but only if it's reasonable :-)09:49
datorich-root-pack is very reasonable :)09:49
Lo-lan-doCool.  I'll upgrade as soon as the branching is done then.  Thanks.09:50
astrawhow do I specify a "merge base revision" with rebase?10:01
dleeI've been sticking to pack-0.92 because I thought all newer stuff was experimental.  I use bzr 1.0 and nothing older for projects I'm starting or transferring into it.  Should I switch now to something else for any reason (I know bzr-svn needs rich-root, but other than that...)?  I need not to risk data loss or problems my would-be Bazaar collaboraters could hit with newer formats,10:14
dleebut if it's safe to use something newer already, it could save me a lot of upgrades later.10:14
dleeI don't know what the -subtree variants of formats are either... I keep mixing that up with nested-tree, for which I wait anxiously. :)10:15
Lo-lan-doFrom what I understood, the -subtree variants has been replaced by rich-root10:16
dato-subtree is the format of the repository needed for the nested-tree functionality. as it is regarded as experimental, rich-root was created, which is afaik a very small (and safe) subset of -subtree, and it's enough for bzr-svn's purposes.10:18
datodlee, Lo-lan-do ^10:18
dleeLo-lan-do: I thought there was a rich-root-subtree, but I'm probably wrong; it's not listed in 'bzr help formats' (1.0) anyway.10:18
Lo-lan-doNested trees aren't implemented yet, right?10:19
datodlee: also, if you are not using bzr-svn, pack-0.92 should be enough for you, and afaik rich-root-pack would give you nothing (but if you fear upgrades, you could anyway upgrade)10:19
datoLo-lan-do: "work in progress TM" afaik10:19
dleedato: I'm setting up (hopefully) to convert about 40 projects at work into Bazaar (if I can get everyone to use Bazaar), so this is more about picking a format to start with as part of that process.10:21
dleeI think I am to where I just need to deal with a line ending issue (I discussed that in here last night I think), then the conversion process will be ready to test on a fairly large scale...10:22
jmhodgesi'm missing something obvious.  trying to do a bzr rspush to 'deploy@biggecko:/home/deploy/bzr/atelier-main'.  i can login into ssh via deploy@biggecko just find, and the bzr directory is there already. what am i missing?10:24
=== cprov-ZzZ is now known as cprov
datoAfC: markdown is pretty cool10:52
fullermdI've never managed to get my interest piqued by any of that class of formats   :|10:56
=== mrevell is now known as mrevell-lunch
=== mrevell is now known as mrevell-lunch
AfCdato: it's lovely to work in12:20
AfCOne can, of course, use anything ... including raw HTML for that matter;12:21
AfCthe point I was trying to encourage is that the front side web site can and should be in version control12:22
AfC(ideally right alongside your source code, but that's up to you; but it works out nice when doc/* is right in the sources and in the website both)12:22
AfCthus allowing the thing to be static or nearly so (thereby allowing things like Expire headers to be sent properly)12:23
AfCnot to mention WAY faster12:23
AfC(wikis are always terribly slow for some reason)12:23
AfC(and Bazaar's website is terrible in this regard)12:23
AfC... but I like Markdown because it is so unobtrusive;12:24
AfC*especially* because it means the documentation can be nice 80 or so character wide text files readable in a terminal with less right there in your source tree;12:25
AfCor rendered to HTML for the pretty factor online.12:25
AfCIt's all about having your cake and eating it too :)12:26
datoanyhow, if ReST is used elsewhere for bazaar documentation, I doubt another markup format would be adopted12:26
AfCdato: very likely.12:26
AfCdato:  find ReST to be unnecessarily overweight, but that's a side issue12:26
AfCdato: the main point was getting text based doc sources to drive the website but be in the source code or very near it12:27
AfC(thereby allowing patches, review, etc but most of all a flow of information that allows anyone to contribute but still allows a measure of consistency and refinement)12:28
AfC[The part I love is that your entire website can be a single 404 page: ask for BzrVsGit.html and, not finding such a page, the 404 handler checks to see if BzrVsGit.txt exists. It does, so it renders it. Done. Ta-da.12:29
AfC(and you can cache if you like by writing BzrVsGit.html, but that's not necessary)12:29
=== mrevell-lunch is now known as mrevell
abentleyAfC: Achitecturally, I see little difference between Moin-markup-in-moin-vcs and Markdown-in-Bazaar.12:43
AfCabentley: the difference is that you access the whatever-in-$VCS directly, and the same [review and approval] paths apply.12:47
AfCYou can edit text files properly and then submit changes as patches, instead of working in random edits through some cumbersome web-app front end that has no quality control12:48
abentleyI don't think that's an improvement.12:50
abentleyI like the instant feedback of vcses.12:50
abentleyOf wikis, I should say.12:50
abentleyAnd the same people who review code also keep a close eye on the wiki.12:50
abentleyThe pages that are coming in for the most criticism at the moment are BzrVsHg and BzrVsGit, and both were written by Ian, with tweaks from myself and others.12:51
AfCabentley: well, you and I disagreeing about fundamentals is nothing new12:53
AfCabentley: but the quality problems with the Bazaar website far far exceed those two pages.12:54
AfCboth in terms of content and performance.12:55
Lo-lan-doHi again.  Can I disable a plugin for just one invocation of bzr?  With a CLI parameter maybe?12:56
datonot only one afaik12:56
abentleyLo-lan-do: bzr --no-plugins12:56
Lo-lan-doHm.  It'll do.  Thanks :-)12:57
AfC'night all12:57
Lo-lan-doIs it possible to store that in a branch-specific config file?12:58
abentleyLo-lan-do: no12:58
abentleyWhy do you want that?12:58
Lo-lan-doActually, in a lightweight-checkout-specific would be even better.  But I'll manage.12:58
Lo-lan-doI have a bzr branch inside which I did an svn checkout of a subdirectory (debian/).12:59
Lo-lan-dobzr commit debian/changelog complains that an assertion has failed, presumably because the svn checkout isn't rooted at the same point as the whole bzr branch.12:59
Lo-lan-doIgnoring the bzr-svn plugin for operations seems to fix the problem for me.  I can live with --no-plugins :-)13:00
Lo-lan-doBut if there's a better way, by all means tell me about it :-)13:01
abentleyThis sounds a lot like a bug in bzr-svn.  It should just try to commit to the svn repo.13:01
Lo-lan-doI don't want it to.  I'm doing a one-way gateway.13:01
abentleyYeah, but there definitely shouldn't be assertion failures.13:02
abentleyMaybe there should also be a way to flag an svn checkout so that bzr ignores it.13:02
abentleyAnyhow, if you could report the assertion failure against bzr and bzr-svn, that would be helpful.  We can sort out where the bug actually lies.13:05
Lo-lan-doWill do13:05
abentleyI think causing .svn directories to be ignored is a bzr-svn issue, because presumably you'd need some metadata in the .svn directory to do that.13:07
abentleyBut you can also control your plugins by setting your plugin directory.13:07
abentleyIf you set the BZR_PLUGIN_PATH environment variable to a directory that doesn't contain bzr-svn, that should also disable it.13:08
dleeAny way to push a conflicting (locally moved via --force) tag?13:33
dleeThe help for that looks dangerous... does that also erase stuff others might have pushed to the same repo?13:36
luksit does not erase anything in the repository13:36
luksbut it does overwrite the branch history in case they are diverged13:38
dleeI'm having trouble understanding the difference between overwriting history and erasing info (by overwriting it) in the repo.13:40
luksrepository is a storage for revision data, branch is a pointer to a revision in the repository13:41
luksso if your remove branch is on rev2, and you are pushing branch that is on rev1 with --overwrite it will set the pointer to rev113:41
luksbut rev2 is still in the repository13:42
luksas far as I know, none of the current formats will remove any data from the repository on push13:42
luksit's similar to uncommit locally, where you also only change the pointer13:43
dleeHmm... I thought uncommit removed data also.13:43
dleeSo I commit rev 320, uncommit it, and commit again.  I'll get a new 320 but have both 320's in the repo somehow, with one being inaccessible??13:44
dlee(Disclosure:  I've not used uncommit :)13:45
luksusing revnos makes sense only in context of a branch13:45
luksbut yes13:45
dleeDoes anything then provide access to, or show, the first r320?13:45
luks-r revid:<revision-id>13:45
dleeAh... you'd probably need the revision ID...13:45
dleebut without pulling it directly like that, you'd never see it again.13:46
luksunless somebody else pulled/merged the branch before uncommitting13:47
luksbut you probably won't use uncommit on a public branch13:47
dleeMakes sense... now just trying to figure out what could be messed up if I push a tag move while others are pushing stuff up to the same repo...13:47
luksto the same branch or repository?13:47
lukswell, in any case, nothing13:48
luksbecause push requires a lock13:48
dleeActually... are branch, repo, and shared repo all three different things?  I know what a shared repo is pretty clearly.13:48
luksbzr push complains about conflicting tags and not diverged branches, --overwrite should be quite safe thing to do13:48
luksthere is no technical difference between repo and shared repo13:49
dleeyes, but that makes non-atomic the whole process:  push, get a tag conflict but not a diverge notice, push again but discover someone else just pushed inbetween...13:49
lukshm, right13:50
dleeI wonder if we should have a way to --force just tag settings?  Not fully thought out...13:50
dleeI actually thought earlier about whether anyone would have a use for a strictly local type of tag that does not push, but again, not thought out.13:51
foghi *, I have a problem with bundle/merge without a central repository:14:07
fogmachine A initialize and repo and commit revno 114:07
fogmachine B branch from machine A at revno 114:08
fogmachine A gets 2 more commits (revno go to 3)14:08
fogthen we are disconnected and I want to pass changes 1..3 from A to B using a bundle14:08
fogon A: bzr bundle -r1..314:08
fogon B: bzr merge thebundle14:09
fogat this point merge fails and says that revision XXX (it is the id of revno 3 on A) can't be found in B14:09
foglog on B show the correct id for revno 1 on A14:09
fogso, why do it fails?14:10
fogseems to me that B has evenrything needed to do the merge14:11
fogthere is something that I am missing?14:11
jameshas a bit of extra context, the resulting bundle appears to assume that the recipient has all the revisions passed in the revision spec14:12
jameshI am pretty sure that "bzr bundle-revisions -r X..Y ." used to produce a usable bundle for for a branch containing X14:14
jameshlooking at the help text, I think it is a regression14:19
datothe bundle probably does not include the revisions because the submit branch does contain them14:30
fogdato: the bundle does not contain the bundle (but it contains the diff!)14:31
fogI just did a test and if I branch locally at -r1 and then pass that as the argument, the bundle is correct14:32
foglet suppose my original branch is in XXX14:32
fogbzr branch XXX -r 1 XXX.ouch14:32
fogcd XXX14:32
fogbzr bundle -r1..3 -> does not work14:32
fogbzr bundle -r1..3 ../XXX.ouch -> works14:33
dato(personally I believe that whenever -r is specified, those revisions ought to be included in the bundle metadata no matter what, but maybe abentley has a good reason why it shouldn't be like that)14:33
datoabentley: ^14:33
datofog: correct14:33
fogdato: ok, but ... why? I feel extremely stupid here and I just don't understand why I need an "extra" branch to generate the bundle.14:34
datofog: abentley would be the person with the canonical answers here. the idea is that you generate a bundle in order to apply it to some target branch (the "submit branch"), and not as a means of arbitrarily bundling up revisions from the repository14:35
datopersonally, what I said above about -r being specified, but I cannot do more, I'm afraid14:35
fogdato: ok, so the new question is "how do I arbitrarily bundle up revisions from the repository"?14:35
fogbecause creating a new branch every time I want to send something to a collegue is inelegant (it is cheap, ok)14:36
radixyou shouldn't need an extra branch, you should already *have* an extra branch :)14:38
radixI'm not sure exactly of your use case here, but generally, if you're developing each feature or bugfix (or whatever concrete change) in its own branch, then things work out nicely14:38
fogradix: why should I have the branch my colleague is working on?14:39
datofog: how do you know which revisions you have to send?14:39
radixI don't know what you mean by that14:39
jameshfog: I often keep copies of branches I need to access when offline14:40
jameshfog: given the setup you described, you are effectively offline from your colleague so it could be useful to have a local mirror14:41
jamesh(for more than just this case, which I consider a bug)14:41
fogdato: we keep in touch by email and usually is just the last one.14:43
fogjamesh: yes; I think this is the best approach14:43
fogdato: it is something like "I fixed this bug, merge now istead of tomorrow when we're togheter at the office"14:44
datofog: *personally* I'd just publish my branch somewhere, and have them pull from there. maybe in a private server over sftp if the code is not public.14:44
datofood time, bbl14:45
foganyway, I understand why it works that way.14:46
fogthank you everybody.14:46
jelmerdlee: yeah, pack-0.92 would be the best choice. I think it's also the default now14:51
Lo-lan-doHi jelmer14:54
jelmerhey Lo-lan-do14:56
Lo-lan-doI suppose you've seen my latest bug reports? :-)14:56
Lo-lan-doThere's no hurry, really, I just didn't want to forget about them.14:58
jelmerthe first one's already closed14:59
fogjamesh, dato: ok, everything is working. thanks again.15:04
=== mw|out is now known as mw
dleejelmer: thanks15:11
ubotuNew bug: #181520 in bzr "bzr log FILE don't show revisions where file was removed" [Undecided,New] https://launchpad.net/bugs/18152015:20
dleeVerification of my understanding of where nested-trees are going:  If I now (in pack-092) create a branch "proj" that contains subdirs "proj/a" and "proj/b," can I (when nested-tree comes out) upgrade my branch and then do something like "bzr co (path)/proj/a" to get just the "a" part in its own branch?15:28
dleePlanning project layouts here...15:29
jelmerdlee: that's partial checkouts15:37
jelmerdlee: nested trees would be the ability to add one branch to another other or "upgrade" a directory in a branch to a branch15:38
dleeWhat's the status of partial checkouts then?16:02
jelmerdon't think there's anybody working on them at the moment16:03
dleeScenario (hopefully not summarized beyond comprehensibility):  We do development in an environment where it is sometimes advantageous to have a "live" checkout--one in a directory of files managed (or partly managed) by a running program.  To do this requires that there be no directory names/levels above the files:16:04
dleeIn my example, I would need .bzr to be in the folder with the files.  It's fine to check it out as "a," but then I'd move the files and .bzr to where the live system is.  We do this so the VCS can catch changes made from GUI screens to config files etc. among other reasons.16:06
dleeCVS and Svn support this, though maybe not by design so much as happenstance.16:06
jelmeryou may be able to work around it a bit using nested trees, but what you really what (as I understand it) is support for partial checkouts16:07
jelmerprobably best to bring it up on the mailing list, I'm not sure what the plans in this area are16:08
datodlee: so proj/a and proj/b really belong in the same branch?16:08
dleeSo a determining question:  If my branch is (as above) proj with proj/a, proj/b, etc., is there now (or do you think there soon will be) a way for me to arrange that "bzr commit ..." can be issued from a dir containing proj/a's files but without requring that the folder be named something/a or proj/a?16:09
dleeWe do work for many companies, and the standard here is to make (in CVS now) a dir for each company.  Most of those are just one project, but some contain several.16:10
dleeOften, the code for different projects for one company *are* related or share common components.  We do accessibility work, and the code is mostly scripts for a product called JAWS (http://www.freedomscientific.com).16:12
jelmerdlee: I don't think there is a way to do that at the moment16:16
jelmerdlee: There will be a way to do that with nested trees because you could make each company's directory a separate branch16:16
dleeI figured that, but I also figured it was soon coming... looks like I may have to rethink a couple plans. :)16:16
jelmerthe code is there, but it's still experimental16:17
jelmerand a couple of tests for it are still broken16:17
jelmers/broken/not passing/16:17
jelmerI'm not sure how much it is to get those to pass16:18
jelmerLarstiQ: ping16:18
dleeSample structure, each dir of which should allow checkout: co1 (one proj so no subdivision), co2, co3, co3/a, co3/b ...  (co3 AND co3/a and co3/b should be checkoutable if possible)16:18
dleeIf not checkoutable, as I said, at least we'd want a way to go "cd co3/b; mv * (including .bzr) (live path); cd (live path); (work on stuff); bzr commit ..."16:19
dleeI'll need to assess how many people besides me really do this I guess. :)  It may be mostly me...16:20
StavrosI want to version my various system config files, but i imagine making a repository at the root would not be advised, correct?17:19
dleeI don't see a problem with that if you don't do 'bzr add' and scan the entire filesystem into your repo. :)  But I'm assuming things like "bzr commit" (without filenames) will *not* scan the whole fs... I think I'll experiment with this myself.17:26
Stavrosdlee: doesn't it search the whole fs when you do a status/commit though?17:26
Stavrosfor unknown/unversioned files?17:27
dleeI'm new enough to Bazaar not to be sure of this yet... but I do get an error on 'bzr init' in /17:29
Stavrosdid you run as superuser? :P17:29
Stavrosi think it'll scan everything though, i wouldn't try it :)17:29
dleeYes, and I got this on bzr init:  bzr: ERROR: Transport error: rrno 21] Is a directory: '/' rrno 21] Is a directory: '/'17:30
Stavroshaha, wow17:31
Stavrossounds like a bug17:31
Stavrosi don't think anyone expected anyone to do that :P17:31
dleeI have a small FreeBSD system here; if it scans the whole box, all that happens is my mail gets slow :)17:31
Stavrosah, okay then :p17:32
dleeWorkaround:  cd /tmp; bzr init; mv .bzr ..17:34
dleeI'll probably file a bug on the above error, though I doubt a lot of people are inconvenienced by this one.  Certainly a corner case :)17:34
Stavrosi'd say :p17:34
dleeTo your original question:  All else I'd say is to watch those perms... you pull a file full of passwords into a repo, beware who else can read it...17:35
Stavrosah, noone will, but i am still afraid that it'll scan the whole system17:36
ricardokirknerhi. I just found out that bazaar tracks changes in the execute bit of the files. Just out of curiosity, is there any way I could tell bzr to ignore that bit on certain files?17:39
ricardokirkneror, is there a way to see in what what did the permissions change?17:41
jelmerricardokirkner: atm you can only ignore /all/ changes on a file17:42
jelmerricardokirkner: bzr log -v will show a "*" next to the file17:43
jelmerwhenever the execute bit changes17:43
LarstiQjelmer: pong18:35
luisbga bzr push to launchpad got cut midway because I lost the internet connection, now I'm trying to push again and it tells me it can't create because it already exists18:51
luisbg how do I fix this?18:51
luisbg bzr: ERROR: Can't rename ... already exists18:51
jelmerLarstiQ: Was just wondering whether there was anybody workin on nested trees atm18:51
jelmerLarstiQ: Also, are you going to the sprint?18:51
LarstiQjelmer: I don't know.18:51
LarstiQ(on both accounts)18:51
Pengluisbg: bzr break-lock $URL18:52
LarstiQjelmer: I'd like to, but atm I'm not really contributing anything.18:52
luisbgPeng, sorry for the hazzle but what should the $URL be?18:52
luisbgthe push location? going to try :)18:54
luisbgPeng, thanks a lot!!!18:55
jelmerLarstiQ: I still have time for the occasional bzr-svn patch, but shallow branches are still on my list :-/18:57
PengUhm, how do I reverse a revision?19:04
jelmerpeng: like uncommit?19:04
jelmeror commit the reverse of it?19:04
Peng"bzr merge -r 10..9 .", right?19:05
PengIt's doing nothing.19:05
jelmerand commit19:06
PengWell it's not doing anything.19:06
PengIt says "All changes applied successfully." but doesn't change a thing.19:06
jelmerbzr st doesn't show anything either?19:06
jelmerdoes not specifying "." change anything?19:07
jelmerit shouldn't, I think, but I never specify .19:08
LeoNerdTry   bzr di -r 10..9    first, to see if that revision actually has any changes19:08
LeoNerdIt's possible to make empty commits19:08
ubotuNew bug: #181585 in bzr "bzr push --create-prefix sftp:// crashes" [Undecided,New] https://launchpad.net/bugs/18158519:16
PengOops, forgot about this.19:33
Pengjelmer: I dunno. It contacts the server.19:34
PengLeoNerd: It added a few files.19:34
Pengjelmer: Yeah, that worked.19:34
jelmerwith a path means a cherrypick I think19:37
PengOf course it's a cherrypick.19:37
jelmerno, it's an inverse cherrypick19:37
jelmerI'm not trying to justify it, it is a bug.19:38
jelmerthere are probably two codepaths19:38
jelmerone that works on a part of the tree (when a path is specified)19:38
jelmerand one that works on the full tree (when no path is specified)19:38
datowell, without a path19:44
datothe -r argument refers to the remote/parent location, ain't it so?19:44
=== niemeyer_ is now known as niemeyer
jelmeryes, but in the root of the branch, "." does change the meaning19:57
=== Peng_ is now known as Peng
datojelmer: ah20:13
datojelmer: I thought it just meant "this branch", at least for merge20:13
jelmerI meant *does not* change the meaning20:13
jelmerbad typo20:14
PengWhat did I miss?20:29
PengLast I saw was "the -r argument refers to the remote/parent location, ain't it so?".20:30
dleeMy experience is that "." is required for this sort of backout "merg":  "bzr merge -r10..9" gives me an error, but "bzr merge -r10..9 ." seems to work.20:44
PengYeah, and just now for me, . did nothing and no-. worked.20:45
dleeI'm assuming that "bzr merge -r10..9 ." is *the* way to reverse a commit so I can commit it again; I discussed this recently in here actually.  If there's a better way, I'm all ears.  "cherry pick" sounds bad to me now because of it messing with merges in general, but I'm not sure it's a problem for this case.20:45
Peng(but no-. contacted the server)20:45
PengFWIW, hg has a "backout" command to do it. It also makes the new revision a child of the old one.20:46
dleePeng: Um...?  Interesting... so periodless reversals can work... (files in the "unsolved mysteries" corner of the brain :)20:46
PengWorks fine in a simple test branch.20:49
datoI insist that if it works without the dot, it must be because you have a parent where the revision you specified with -r is the revision you want to back out20:56
datoas for why it won't work with the dot, I agree that'd be a mystery20:56
pygihey poolie21:01
lifelessdlee: its documented in bzr help merge I think ;)21:02
pygipoolie, nice to see sprint announced :)21:02
pygiI was just about to mail you to ask you about the idea I had, and sponsorship21:03
pooliei hope you can come21:03
pooliedo you want to tell me now?21:03
pygiwell, sure21:03
pygibasically I wanted to work on a Personal Revision Control for Gedit21:04
pygiSo you can commit regular milestones of your documents, and put comments on each of them21:04
pygiofcourse, all that powered by bzr :)21:04
pygipoolie, how bad is idea? :P21:07
dleelifeless:  Which thing are you saying is documented there?21:12
lifelessmerge to reverse commits21:12
dleeUh oh, ok :)21:13
radixit depends if the commit you want to reverse and re-commit later is a merge... if it is, things are more complicated21:14
dleeI'm not seeing it there.  Am I just missing it, or is it in .dev?21:16
datoI don't see it either21:17
PengNor do I.21:17
lifelesshuh, its not explicit but its there21:20
lifelessI guess adding an example of a negative range will help21:20
lifelessfile a bug or a patch please :)21:21
=== cprov is now known as cprov-out
dleeI might get an rtfm-like answer to this, because I know I haven't looked hard enough yet, but... if there's a quick answer, what do I do to get the right branch for submitting Bazaar patches, and then what's the best way to submit them?  If this is easy to find, I won't be offended by the rtfm-like answer either...just looking to help out between other projects21:46
datob get  bzr.dev; bzr branch bzr.dev bzr.yourfeature; hack & commit; bzr send bazaar@lists.canonical.com21:47
dleeI've seen lp: URLs, but so far I've just pulled plugins via the http: URLs on the Launchpad page.  I think bzr.dev or bazaar.dev is the dev branch name...21:47
datothe location of bzr.dev should be mentioned in the downloading page or so (it's not a lp url)21:47
dleeok thanks21:47
dleeAh, an example of the earlier discussion of "get a local copy of the branch"... I've been doing bzr get; hack and commit; bzr send ... and it's worked.  Then bzr pull when I'm informed of an update.  Not sure why the extra branch is better; might have to reread the earlier discussion.21:49
dfoersterHi. Can anyone help how to debug bzr? I once read about an env variable to drop into a python console on errors. Does this still exist?22:07
jelmerdfoerster: yep, that's BZR_PDB=122:07
PengAlso, .bzr.log and the various -D arguments are helpful.22:08
dfoersterjelmer: thx! I just reopened the bug report about the bzr-svn unicode error. Can't find any trace you applied my patch.22:09
dfoersterjelmer: fyi: I just tried to checkout a 1gig svn repository using bzr-svn and bzr got killed after using more than 80% of the 4Gb(!) memory.23:50
jelmerdfoerster: there is a memory leak in the python subversion bindings23:50
jelmerit has been fixed recently, but there are no packages with the fix yet23:51
jelmersee Subversion issue 305223:51
dfoersteralright, that's good to know23:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!