| Verterok | hi poolie | 00:02 |
|---|---|---|
| * AfC waves to Verterok | 00:06 | |
| Verterok | hi AfC :) | 00:11 |
| lifeless | jelmer: ping | 00:36 |
| jelmer | lifeless: pong | 00:36 |
| lifeless | jelmer: re your virtual files things | 00:37 |
| lifeless | jelmer: I'm guessing you want to avoid code dup between bzr-git and bzr-svn ? | 00:37 |
| lifeless | jelmer: if so, perhaps a good staging place would be bzr-foreignformatsupport or something ? | 00:37 |
| jelmer | lifeless: as in a separate plugin you mean? | 00:38 |
| lifeless | I'm not against the things you are producing coming into the core bzr, but perhaps for other core devs the overall shape of what you are producing is not visible yet | 00:38 |
| lifeless | yes, as in bzr.plugins.foreignformatsupport | 00:38 |
| jelmer | ah, in a plugin but shipped with core? | 00:38 |
| lifeless | well | 00:39 |
| lifeless | I was actually meaning 'keep it completely separate until its more clear' | 00:40 |
| jelmer | I'd rather not require a separate plugin to be installed for bzr-svn and bzr-git to work | 00:40 |
| lifeless | we have the open bug about shipping > bzr's tree on make dist | 00:40 |
| lifeless | hmm, perhaps thats what I should do today | 00:40 |
| jelmer | that means an extra plugin to package and it means requiring users to install yet another plugin for either to work | 00:40 |
| lifeless | well | 00:40 |
| lifeless | you've got a month till 1.7 anyway | 00:41 |
| lifeless | so packaging would be premature right now; and I will have a poke at a dist-many thing today | 00:41 |
| lifeless | evolution is *still* importing :( | 00:41 |
| lifeless | Jc2k: how long did the full evo import take initially ? | 00:42 |
| awilkins | jelmer: Has bzr-svn -.4 moved much in the last week ? | 00:42 |
| lifeless | poolie: bug 252428 as requested | 00:42 |
| ubottu | Launchpad bug 252428 in bzr "stacking must always grab full inventories" [Critical,New] https://launchpad.net/bugs/252428 | 00:42 |
| jelmer | lifeless: well, even though something may be planned to land rsn it may take far more than that so I'd rather not rely on anything until it's actually there | 00:43 |
| lifeless | jelmer: fair enough | 00:43 |
| jelmer | lifeless: alternatively, do you think it's a sane goal to allow repositories to not provide the inventories and revisions versionedfiles? | 00:47 |
| jelmer | instead allowing functions that provide the unmarshalled objects to be returned | 00:48 |
| lifeless | we don't generally want to go up to objects at all | 00:48 |
| lifeless | e.g. diff shouldn't need a full Inventory; that doesn't scale | 00:48 |
| lifeless | (for inventories I mean) for revisions we have object methods already | 00:48 |
| jelmer | sorry, I should've phrased that differently | 00:49 |
| lifeless | The stated goal of the versionedfiles attributes is that other objects that *understand* a particular serializer can use them to do direct access | 00:49 |
| lifeless | e.g. stacking | 00:49 |
| jelmer | I don't mean Inventory objects just python objections in general, e.g. inventory deltas as well | 00:49 |
| lifeless | so, I think its completely fine to have None for those attributes as long as you have a unique serializer, and your code knows how to do all the operations that in the generic Repository are implemented in terms of those attributes | 00:50 |
| jelmer | at the moment, that would horribly break stacking though | 00:51 |
| lifeless | I don't think its desirable, but I will agree that having unoverridablecode require them is a bug | 00:51 |
| jelmer | that's why I've got them implemented at the moment | 00:51 |
| lifeless | jelmer: stacking will always depend on them | 00:51 |
| lifeless | jelmer: at least for the foreseeable future | 00:51 |
| lifeless | (the 1.6 format stacking logic depends on the same /representation/ to apply deltas across repositories) | 00:52 |
| lifeless | and these attributes are about providing access to representation | 00:52 |
| jelmer | that's what my question was though | 00:53 |
| lifeless | if/when we get a stacking facility that does not depend on representation (which group-compress is shaping up into fwiw) then we can do the (non-trivial) work to make every single method stacking aware | 00:53 |
| jelmer | do you think it's a sane goal to work on allowing stacking on repositories that don't have the same representation? | 00:54 |
| lifeless | yes | 00:54 |
| jelmer | ok, that's what I was hoping to hear :-) | 00:55 |
| jelmer | I may look into that depending on how hard it is, but I probably won't have enough time | 00:55 |
| lifeless | I suspect its non trivial | 00:55 |
| jelmer | for now I'll just keep copies of my VirtualVersionedFiles classes in both bzr-git and bzr-svn | 00:56 |
| lifeless | *every* method that accesses the storage attributes today will need to be taught to stack, and every data-access method needs to fail in such a way that lookups can then be made to the different source | 00:56 |
| lifeless | it was hard enough doing it on just the 8 or so methods of VersionedFiles | 00:57 |
| jelmer | lifeless: this would only be for revisions and inventories though | 00:57 |
| lifeless | k | 00:58 |
| jelmer | lifeless: "bzr branch" works in bzr-git now (again?) btw | 01:02 |
| jelmer | I haven't been able to figure out why though | 01:02 |
| jelmer | it seems just implementing get_revision(), revision_tree() and get_ancestry() on Repository was sufficient | 01:03 |
| jelmer | which is quite scary, really | 01:03 |
| poolie | lifeless: would it also work to require the first commit of an inventory in the new repository to require a full text? | 01:03 |
| poolie | i mean store a full text | 01:03 |
| lifeless | poolie: pull(other repo) can introduce deltas | 01:05 |
| lifeless | poolie: so I don't think its sufficient, or necessary | 01:05 |
| === sdboyer_ is now known as sdboyer | ||
| poolie | lifeless: it seems like we need to check the models are compatible every time we add_fallback_repo, do you remember if we do | 01:22 |
| lifeless | poolie: yes, we do | 01:25 |
| lifeless | if not self._add_fallback_repository_check(repository): | 01:26 |
| lifeless | raise errors.IncompatibleRepositories(self, repository) | 01:26 |
| lifeless | which is | 01:26 |
| lifeless | return InterRepository._same_model(self, repository) | 01:26 |
| lifeless | jelmer: I'd really suggest a plugin for the common code rather than having duplication; one extra branch command for early adopters really shouldn't be a show stopper IMNSHO | 01:29 |
| lifeless | jelmer: but up to you | 01:30 |
| jelmer | lifeless: I'm getting enough bug reports from people not using the right combination of (bzr, bzr-svn, svn) as it is, would rather not make that a 4-tuple | 01:30 |
| jelmer | lifeless: also, not looking forward to finding a sponsor for yet another debian package | 01:31 |
| lifeless | jelmer: well, you could always roll the code into either bzr or each plugin at release time; but like I say, its your call | 01:32 |
| jelmer | lifeless: sounds like more overhead for myself than copying two files over each time I change them | 01:33 |
| jelmer | of course, I could always make bzr-git depend on bzr-svn.... :-P | 01:33 |
| jelmer | lifeless: any reason why having two copies is a particularly bad idea, other than the fact that code duplication in general is bad? | 01:34 |
| lifeless | jelmer: because it makes testing the impact of a change harder for you | 01:36 |
| jelmer | poolie: did you see bug 251871? | 01:38 |
| ubottu | Launchpad bug 251871 in bzr "assumes source_branch format is the same as result branch format" [High,New] https://launchpad.net/bugs/251871 | 01:38 |
| lifeless | bye bye firefox, OOM killed | 01:43 |
| === abentley1 is now known as abentley | ||
| Odd_Bloke | bOOM headshot. | 01:53 |
| lifeless | Odd_Bloke: :) | 02:07 |
| lifeless | jelmer: can you make 'bzr branch lp:bzr-svn' DTRT - that is download the current development bzr-svn suitable for use with bzr.dev ? | 02:11 |
| jelmer | lifeless: that should already be the case | 02:14 |
| lifeless | jelmer: cool | 02:14 |
| poolie | jelmer: not yet, looking | 02:18 |
| jelmer | lifeless, did you intend to close the bzr-svn task of bug 252259 as invalid as well? | 02:22 |
| ubottu | Launchpad bug 252259 in bzr-svn "SystemError: Parent module 'bzrlib.plugins.search' not loaded" [Undecided,New] https://launchpad.net/bugs/252259 | 02:22 |
| lifeless | jelmer: no, that was my comment 'lets see if launchpad knows what I mean' :) | 02:23 |
| lifeless | jelmer: what did my email do to the bug precisely? | 02:26 |
| jelmer | lifeless: it marked the bzr-search task as invalid and opened a task for bzr-svn | 02:27 |
| jelmer | then the next email seemed to mark the bzr-search task as invalid again | 02:27 |
| lifeless | did it mark the bzr-svn task as invalid too ? | 02:27 |
| lifeless | (the next mail ? ) | 02:27 |
| jelmer | no, that's New atm | 02:27 |
| jelmer | no, that just marked the bzr-search task as invalid *again* | 02:27 |
| lifeless | so I sent one email; and I wanted it to make the bzr-svn bug invalid and the bzr-svn one new | 02:28 |
| lifeless | oh | 02:28 |
| lifeless | I sent two emails | 02:28 |
| jelmer | lifeless: You may want to rephrase that :-) | 02:28 |
| lifeless | EContext | 02:28 |
| jelmer | marking the bzr-svn bit as both invalid and new doesn't make sense | 02:29 |
| lifeless | righto, I think its probably some nasty import error somewhere | 02:29 |
| lifeless | the SystemError smells of svn bindings or something to me | 02:29 |
| lifeless | but yeah, I would have like to close the bzr svn bit too | 02:29 |
| lifeless | done by hand | 02:29 |
| awmcclain | Sorry for the off-topic question, but which channel would I go to with PPA problems? ubuntu-motu? | 02:49 |
| jelmer | launchpad I think | 02:51 |
| lifeless | #launchpad for PPA specific issues (timeouts, crashes in the facility etc) | 02:54 |
| lifeless | #ubuntu-motu if you just want a hand driving PPA's as they have most of the mentors etc | 02:55 |
| awmcclain | Gotcha. | 02:55 |
| alecwh | Where can I read about sending bzr patches over email? | 04:21 |
| RAOF | bzr help send? | 04:22 |
| mlh | er | 04:22 |
| RAOF | Too slow, apparently. | 04:22 |
| mlh | yeah, lift your game :-) | 04:23 |
| alecwh | Where can I read about sending bzr patches over email? | 04:23 |
| mlh | ooh here he is again :-) | 04:23 |
| mlh | bzr help send | 04:23 |
| alecwh | sorry, I accidentally quit. =\ | 04:24 |
| mlh | happens to the best of us old chap | 04:24 |
| spiv | alecwh: also, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#sending-changes | 04:24 |
| === thunderstruck is now known as gnomefreak | ||
| === jamesh_ is now known as jamesh | ||
| * mwhudson pushes the new loggerhead theme to trunk!!! | 06:27 | |
| lifeless | mwhudson: congrats | 06:29 |
| lifeless | beuno: you too | 06:29 |
| poolie | woo | 06:40 |
| poolie | well done | 06:40 |
| Peng_ | Yay. :) | 07:00 |
| spiv | http://www.toolness.com/wp/?p=71 is interesting. I guess these people would really like bzr's checkout workflow? | 07:15 |
| mwhudson | spiv: i wondered whether that was 'ooh, don't really like hg' or 'oooh, don't really get dvcs' | 07:21 |
| mwhudson | (sprinting so didn't really have enough spare brain cells to actually read the blog post properly) | 07:22 |
| spiv | mwhudson: it's hard to tell from this distance, really. Especially if the only dvcs they've used is hg... | 07:29 |
| poolie | spiv/lifeless: i want to give better messages when repositories are not compatible | 07:57 |
| poolie | for stacking or other reasons | 07:57 |
| poolie | at the moment you just get told they're not and that's it, so not much help to a user | 07:57 |
| poolie | i'm planning to add an alternative api to InterRepository.is_compatible which raises an exception (rather than returning False) if they're not | 07:57 |
| poolie | so we get to keep that information | 07:57 |
| poolie | any comments? | 07:57 |
| * bob2 gives polite 'yay' | 07:58 | |
| spiv | poolie: I like the sound of that. | 08:00 |
| poolie | eg https://bugs.edge.launchpad.net/bzr/+bug/206258 | 08:03 |
| ubottu | Launchpad bug 206258 in bzr "incompatible repository error messages are unhelpful" [Undecided,Confirmed] | 08:03 |
| lifeless | poolie: is_compatible is used for selecting an optimiser | 08:04 |
| lifeless | poolie: so having one that raises an exception doesn't feel right to me, I can just see use spewing out 10 different incompatibilities | 08:05 |
| lifeless | s/use/us/ | 08:05 |
| poolie | if you're searching for one where it passes you would not print them | 08:06 |
| poolie | and we can keep a method that just says 'did it pass' | 08:06 |
| lifeless | I'm talking the failure mode | 08:06 |
| poolie | essentially we have at the moment | 08:06 |
| poolie | if not foo(): raise Exception(generic) | 08:06 |
| poolie | and i want to invert that | 08:07 |
| poolie | hm unless there is one method for matching and another for checking? | 08:07 |
| lifeless | there are N optimisers | 08:07 |
| lifeless | when none match that will give you N exceptions | 08:07 |
| lifeless | which one will you show? | 08:07 |
| lifeless | I think what you want to achieve is good; I'm all in favour of clearer error messages | 08:08 |
| lifeless | Jelmer has a patch that improves the KnitRepository __str__ to make the rich-roots->plain case more understandable | 08:08 |
| poolie | hm | 08:08 |
| poolie | at the moment i actually want to change _same_model, which while it lives in InterRepository is apparently not multiply-dispatched | 08:09 |
| poolie | being a static method on the base class | 08:09 |
| lifeless | but a different model doesn't imply an error message | 08:09 |
| lifeless | its a very specific combination of models that generates an error | 08:09 |
| spiv | Do we need "incompatible_model"? | 08:09 |
| lifeless | *everything* is compatible except for "rich-root or subtrees to plain" | 08:10 |
| poolie | i don't think that's actually true | 08:11 |
| poolie | there are more implementations of it that check requirements with weaves and knits | 08:11 |
| lifeless | oh? | 08:12 |
| poolie | to answer your earlier question if we are searching for a match and none of them matches | 08:12 |
| poolie | no, i don't think it would be useful by default to tell the user of every possible thing we tried and why it failed | 08:12 |
| poolie | but i can believe having that information available for debugging might be useful | 08:12 |
| poolie | into the log or something | 08:12 |
| lifeless | via a -D flag perhaps | 08:12 |
| poolie | right | 08:13 |
| lifeless | quite seriously though, I don't believe there are any other cases where is_compatible falls all the way back to the default implementation | 08:13 |
| lifeless | there are various InterFORMAT ones | 08:14 |
| lifeless | there is InterSameData | 08:14 |
| lifeless | and InterModel1and2 | 08:14 |
| poolie | ok | 08:14 |
| poolie | i'm going to poke at it a bit more | 08:14 |
| lifeless | so the only case I know of is Model2and1 that will fail | 08:14 |
| lifeless | *other* fetch failures can occur | 08:15 |
| lifeless | but they occur once a selection has been made | 08:15 |
| philn | jelmer: ping | 09:21 |
| Jc2k | lifeless: sorry i have no idea | 10:06 |
| Jc2k | the initial import of all of GNOME ran over a few days, with me stopping and starting as i hit bzr-svn leaks | 10:06 |
| Jc2k | and the initial import of SVN was only of trunk, i then used svn-import to "top up" and pull the 2000 branches over | 10:06 |
| james_w | http://www.toolness.com/wp/?p=71 | 11:41 |
| james_w | I'm not posting that as "Bazaar is better than Mercurial", it's s/Mercurial/Bazaar/ as you read and get an idea of how some people dislike DVCS. | 11:42 |
| === doko_ is now known as doko | ||
| spiv | james_w: yeah, I saw that | 12:02 |
| spiv | james_w: although I think bzr's checkout workflow would answer a bunch of the concerns tehre | 12:02 |
| james_w | it's odd that he seems to consider a clean merge more dangerous than a clean update | 12:03 |
| spiv | james_w: there's room for argument, but it's certainly possible to read the core problem as "I don't want the overhead of tracking/merging lots of branches, but the tool doesn't give me any options other than to make branches" | 12:03 |
| james_w | that's true | 12:04 |
| luks | I think it's more about that svn allows you to do 'implicit' update | 12:14 |
| luks | that is, you can commit even if your tree is out of date | 12:14 |
| keithy | hi | 14:12 |
| keithy | how do I tell bzr that the current versions I have are the latest, it seems to think that there are conflicts. | 14:13 |
| james_w | hi keithy | 14:15 |
| james_w | I'm not sure what you mean, could you expand on your question please? | 14:16 |
| keithy | I found it bzr resolve --all | 14:19 |
| TuniX12 | hello | 14:34 |
| TuniX12 | when making a change in a file got by bzr how to upload only that change? | 14:36 |
| james_w | hi TuniX12 | 14:36 |
| james_w | what do you mean by upload? | 14:36 |
| TuniX12 | upload that change to bzr branch | 14:37 |
| james_w | "bzr push" to an existing branch will push only the difference between that branch and yours, if that's what you mean. | 14:37 |
| TuniX12 | ah thank i thought it push all files | 14:37 |
| james_w | no, it won't, but it will push a bit more than just the diff to the changed file, as it will have to push the revision information as well. | 14:38 |
| TuniX12 | and sorry for my bad english :p | 14:38 |
| james_w | no problem :-) | 14:38 |
| === mario_ is now known as pygi | ||
| davi_ | hi, I'm testing 1.6beta3 and I get a error when trying to create a new copy of a branch. The error is AttributeError: 'property' object has no attribute 'initialize' in bzrdir.py, line 1384. Has anyone seen this? is there a fix? | 14:41 |
| TuniX12 | i get this error bzr: ERROR: Cannot lock LockDir | 14:42 |
| TuniX12 | Transport operation not possible: http does not support mkdir() | 14:42 |
| TuniX12 | any solution? | 14:42 |
| davi_ | ah, found bug report. | 14:44 |
| davi_ | would be nice to have a beta4 | 14:44 |
| TuniX12 | ping | 14:46 |
| luks | these people don't have any patience nowodays... | 14:53 |
| === mw|out is now known as mw | ||
| === mthaddon_ is now known as mthaddon | ||
| === thekorn_ is now known as thekorn | ||
| === orospakr` is now known as orospakr | ||
| beuno | yay! new theme landed! | 16:11 |
| === andrea-bs_ is now known as andrea-bs | ||
| strk | [24601] 2008-07-28 17:56:28.680 INFO: Committing to: sftp:/..... | 17:15 |
| strk | Mon Jul 28 18:14:50 CEST 2008 | 17:15 |
| strk | [========================================================================================== ] Uploading data to master branch - Stage 4/6 | 17:15 |
| strk | 18 minutes and counting, for a few lines of commit | 17:15 |
| strk | Bazaar (bzr) 1.5 | 17:15 |
| beuno | strk, can you take a look in ~/.bzr.log ? | 17:16 |
| strk | low bandwidth, all used -- still, is a developer really supposed to suffer this much ? or is it a bad bug ? | 17:16 |
| beuno | there should be something in it | 17:16 |
| strk | lots of 601.406 SFTP.readv() 13 offsets => 1 coalesced => 1 requests | 17:16 |
| strk | 497.074 Auto-packing repository <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x87a8c6c>, which has 17 pack files, containing 10300 revisions into 4 packs. | 17:17 |
| strk | ^^ you're interested in this one most likely | 17:17 |
| strk | or : | 17:17 |
| strk | 128.259 Using fetch logic to copy between KnitPackRepository('file:///home/strk/src/gnash/bzr-local-repository/.bzr/repository/')(<RepositoryFormatKnitPack1>) and KnitPackRepository('sftp://strk@bzr.savannah.gnu.org/srv/bzr/gnash/.bzr/repository/')(<RepositoryFormatKnitPack1>) | 17:17 |
| beuno | strk, right, it's autopacking | 17:17 |
| beuno | it happens every now and then to make things faster | 17:17 |
| strk | it's always autopacking | 17:17 |
| strk | is there a way to make it happen NEVER ? | 17:17 |
| beuno | strk, no, it should only happen once every N commits | 17:17 |
| james_w | not currently. | 17:17 |
| Peng_ | That would be bad for performance. | 17:18 |
| beuno | there is a bug open so that bzr will tell you that it's doing that | 17:18 |
| strk | well, until I'm back on a good connection and ready to wait x*10 minutes | 17:18 |
| strk | performance of what ? | 17:18 |
| strk | it's 24 minutes I'm starving on a commit !! | 17:18 |
| james_w | hopefully we'll have server-side packing soon, which should be much much quicker. | 17:18 |
| Peng_ | james_w: That won't help sftp. | 17:18 |
| beuno | james_w, although server-side packing probably won't work with sftp | 17:18 |
| beuno | :) | 17:18 |
| strk | what happens if I comment out the line where N commits is checked ? | 17:19 |
| strk | I mean, what happens if autopack is NOT done ? where's the performance hit going to be noticed ? | 17:19 |
| strk | or, when | 17:19 |
| james_w | strk: without packing performance will degrade over time. | 17:19 |
| strk | by performance you mean time a commit takes to complete ? | 17:20 |
| Peng_ | Performance in general. | 17:20 |
| Peng_ | That would include committing. | 17:20 |
| james_w | some things will scale with the number of packs, without packing this is the same as scaling with the number of commits, with packing it scales log(number of commits) | 17:20 |
| strk | can it be worst than it is now ? 30 25 minutes ? | 17:20 |
| strk | I'm used to a *few* seconds for similar commits with CVS | 17:21 |
| james_w | yeah, it would include committing. Basically anything that needs to access information in the repository. | 17:21 |
| strk | it's a very small patch | 17:21 |
| strk | and I can thinkg of a few lines of log | 17:21 |
| strk | what else am I missing that needs to generate so much traffic ? | 17:21 |
| james_w | it is packing locally, which means that it is pulling down all of the repository data and pushing it back up organised slightly differently I believe. | 17:22 |
| strk | argh | 17:22 |
| strk | crazy | 17:22 |
| beuno | strk, yes, it is. It will be fixed | 17:23 |
| strk | would a lightweight checkout avoid all of this ? | 17:23 |
| james_w | no, I don't think so. | 17:23 |
| strk | damnit, it's depressing | 17:23 |
| strk | maybe we should setup a cvs commit-hook doing the bzr commit remotely | 17:24 |
| beuno | james_w, I think he should be able to run a cron that packs? | 17:24 |
| beuno | that may mitigate it a little bit | 17:24 |
| strk | done | 17:24 |
| strk | 30 minutes | 17:25 |
| strk | I'm on low bandwidth | 17:25 |
| james_w | yeah, that should help. I assume that the autopack logic looks at the number of packs as well as the number of commits. | 17:25 |
| strk | can't do "offline-commit" forever | 17:25 |
| strk | hard to collaburate with others if I keep all the commits locally | 17:25 |
| strk | was used to do very frequent small commits | 17:25 |
| beuno | strk, you could run a cron to execute "bzr pack" on the branches every... week? | 17:25 |
| strk | beuno: would it need bandwidth ? | 17:25 |
| beuno | that will probably avoid hitting autopacking remotely most of the time | 17:26 |
| beuno | strk, not of the cron runs on the server, no | 17:26 |
| strk | oh | 17:26 |
| strk | that'd be savannah | 17:26 |
| strk | well, I've been online way too much now. lifeless: I hope you can take care of this with savannah hackers. | 17:27 |
| strk | thanks for your patience | 17:27 |
| jam | as an aside, if you ^C during the autopack, the commit still was pushed | 18:30 |
| jam | so it still counts as valid | 18:31 |
| jam | though it isn't something I would generally recommend. | 18:31 |
| james_w | I've got a test problem where calling branch.bzrdir.open_workingtree() seems to either give a different tree to the one that I expect, or doesn't have the changes that were made in the test code. | 19:02 |
| james_w | I think it is the latter, as the path in the repr is correct. | 19:02 |
| james_w | so I create a tree, make a couple of commits, and then make a call that eventually ends up the code I am testing. That code receives a branch, and I need a wt, so I try and open it, and the tree I am given has no revision history. | 19:03 |
| james_w | does this indicate a problem, and that I need to modify the code to provide a working tree directly, as I can never be sure that re-opening the working tree will do the right thing? | 19:04 |
| === cjwatson_ is now known as cjwatson | ||
| jam | james_w: well, re-opening the WT should give the right answer, unless you are using a MemoryTree | 19:31 |
| jam | also, are you sure you are changing the right paths? | 19:31 |
| jam | Often, you might have created the branch/tree in a subdir | 19:31 |
| jam | but then possibly modified the files in the current dir | 19:31 |
| Roumanos | hello, | 20:07 |
| Roumanos | if it some is available, i have a question : | 20:07 |
| Roumanos | it's possible to push on a server my modified file ( not the revision file .bzr ) | 20:08 |
| Roumanos | The commande bzr export work but only on local ( sftp not work with export ...) | 20:08 |
| Roumanos | Thx | 20:08 |
| beuno | Roumanos, you mean the files, but not the revision data? You can use bzr-upload, which will just upload the working tree | 20:08 |
| Roumanos | yes | 20:09 |
| beuno | Roumanos, https://launchpad.net/bzr-upload | 20:10 |
| Roumanos | Perfect ! | 20:10 |
| Roumanos | very thx !!!! | 20:10 |
| Roumanos | exactly what i research ! | 20:11 |
| beuno | Roumanos, your welcome | 20:11 |
| Roumanos | the download page is empty, not yet available ? | 20:22 |
| Roumanos | need to get this by bzr ? :P | 20:22 |
| beuno | Roumanos, not as a release. Are you on Ubuntu? | 20:22 |
| beuno | yes, you get this through bzr :) | 20:22 |
| beuno | mkdir ~/.bazaar/plugins && bzr co lp:bzr-upload ~/.bazaar/plugins/upload | 20:23 |
| beuno | and you're set | 20:23 |
| Roumanos | no sorry, gentoo .... | 20:23 |
| beuno | that should work on Gentoo just as well | 20:24 |
| Roumanos | yes, just need to dl this plugin .... | 20:24 |
| beuno | Roumanos, the command above will work in Gentoo | 20:25 |
| Roumanos | Yes, it's working great ! | 20:26 |
| Roumanos | big thanks for this very quick reponse ! | 20:26 |
| beuno | Roumanos, it's what we do (tm) | 20:26 |
| beuno | feel free to file bugs if you need any additional features | 20:27 |
| Roumanos | ;-) | 20:27 |
| Roumanos | ok, i will look on this plug-in and make a summary later ! | 20:27 |
| Roumanos | thansks | 20:27 |
| aquarius | I'm sure this gets asked a lot (so do please point me at URLs), but what would be the benefits of using bzr rather than svn for keeping my home folder in a VCS? One .bzr folder (rather than one per folder) is good; are there other benefits I don't know about? | 20:33 |
| luks | keeping your home folder in a VCS is a bad idea, no matter what VCS you use | 20:35 |
| aquarius | luks: really? I'm forever losing things, and having numerous different machines and having to repeat the same configuration changes and installations on all of them is jolly awkward. | 20:36 |
| luks | what kind of things are you losing? | 20:37 |
| luks | versioning config files is fine, versioning your whole ~ is not (IMO) | 20:37 |
| aquarius | random files that I accidentally delete, or that I create on one machine and then don't have on others. | 20:39 |
| aquarius | I'm not going to drop my music collection into svn :) | 20:39 |
| luks | if you can accidentally delete a file, I don't think you will always add and commit those random files to a VCS | 20:41 |
| aquarius | no, I agree. I'll still miss some. Not all, though. | 20:41 |
| === mw is now known as mw|food | ||
| luks | I don't know, I really don't like this "versioned file system" idea | 20:42 |
| luks | or, maybe I'd like it, but not in a VCS intended for source code | 20:43 |
| luks | but if you decide to go this way, I don't think you would enjoy using bzr for this (too slow for that kind of working tree) | 20:44 |
| * luks waits for people to disagree | 20:44 | |
| * aquarius nods. That's useful advice, and thanks. | 20:45 | |
| * Jc2k would disagree | 20:47 | |
| Jc2k | we are thinking of using bzr instead of git for our versioned file system | 20:47 |
| Jc2k | though, to be fair, rewriting the bits of bzr we need in c | 20:47 |
| === oohlaf is now known as oohlaf_ | ||
| luks | I wonder why people in #svn so often mention a non-existing command 'bzr unversion' | 20:57 |
| fullermd | They're just being subversive. | 20:57 |
| === oohlaf_ is now known as oohlaf | ||
| aquarius | If I've got a bzr copy of a project in Launchpad, and I want to publish the changes I've made so the project team can look at those changes, am I supposed to publish them to my +junk folder on LP or to the project itself in a branch named by me? Bit confused... | 21:15 |
| james_w | Odd_Bloke: congratulations. Isn't that your first package in Debian? | 21:16 |
| LarstiQ | aquarius: ~aquarius/project/branch-name | 21:16 |
| james_w | hey LarstiQ | 21:16 |
| LarstiQ | hey james | 21:16 |
| aquarius | LarstiQ: ah, excellent. | 21:16 |
| === mw|food is now known as mw | ||
| aquarius | hrm. Confused, again. I bzr pushed to launchpad (thanks, LarstiQ) and it's created that branch, but it's not clear to me that there's actually code there for people to look at. https://code.launchpad.net/~sil-launchpad/gwibber/system-buttons | 21:26 |
| beuno | aquarius, http://bazaar.launchpad.net/~sil-launchpad/gwibber/system-buttons/changes | 21:27 |
| beuno | Launchpad takes a while to scan the commit messages | 21:27 |
| beuno | but your branch is there | 21:28 |
| aquarius | wow! did I miss a link to that page or is it just not there yet? | 21:28 |
| beuno | aquarius, it's not there yet, I cheated. It should be on there soon-ish, and there is a bug open to show that link right away | 21:29 |
| * aquarius grins | 21:29 | |
| aquarius | so I was right to be confused :) Your bug: good work there :) | 21:29 |
| beuno | aquarius, :) | 21:29 |
| abentley | lifeless: ping | 22:22 |
| jam | aquarius: at the bottom of https://code.launchpad.net/~sil-launchpad/gwibber/system-buttons | 22:34 |
| jam | it does say "This branch has not been scanned yet" | 22:34 |
| jam | though I won't say it is very obvious | 22:34 |
| thumper | aquarius: there is a LP rollout shortly that should fix the scanner problem | 22:40 |
| aquarius | jam, thumper: yeah. I didn't know what "scanned" meant -- it seems to mean "no-one can get at this branch yet", which I don't mind, but having a thing which says "this can take a few hours" might not hurt. (Or, just fix the problem by making scanning happen straight away, if that's possible.) | 22:41 |
| jam | well, it is supposed to only take 5 min or so | 22:42 |
| jam | I don't know what the hold up is | 22:42 |
| thumper | jam: the hold up is a bug which causes a mysql branch to fail after 12 minutes | 22:42 |
| thumper | jam: which it tries every time | 22:42 |
| jam | thumper: so it is a 12-min timeout, then it gets another branch scanned, repeat ? | 22:44 |
| thumper | jam: so it gets everything to scan (which may include multiple mysql branches), then does them one after the other | 22:45 |
| thumper | jam: any that fail, get tried the next time around (1m cron) | 22:45 |
| thumper | aquarius: scanning takes bzr metadata and stores it in a database | 22:46 |
| thumper | aquarius: until the branch is scanned we don't show stuff as we don't know what to show | 22:46 |
| aquarius | aha, got it. So the branch might be private in some way or something, so the public can't pull from it until scanning has happened? | 22:47 |
| thumper | aquarius: it is pullable / branchable, but the webapp doesn't know that | 22:52 |
| aquarius | oh, cool. So people who already know their way around LP will be able to get it, at least? | 22:53 |
| thumper | aquarius: yes | 22:55 |
| ryanakca | Could someone help me figure out why I can't bzr init? http://paste.ubuntu.com/31484/plain/ | 23:06 |
| dvheumen | Can anyone tell me how to convert an existing "shared repository with trees" into a "shared repository"? | 23:06 |
| jelmer | ryanakca: bug in bzr-svn, which has been fixed in newer versions of bzr-svn | 23:07 |
| jelmer | ryanakca: as a workaround, try "bzr --no-plugins init" | 23:07 |
| jelmer | dvheumen: You mean into a shared repository without trees? | 23:07 |
| dvheumen | jelmer: yes that what I mean... I tried out 'bzr reconfigure' but I don't know how to change it to treeless | 23:08 |
| ryanakca | jelmer: splendid, thanks :) | 23:08 |
| james_w | dvheumen: would you file a bug about that, I think it should know | 23:11 |
| dvheumen | james_w: do you mean as a feature request? | 23:11 |
| james_w | yes please | 23:12 |
| dvheumen | k, I'll do that, tnx | 23:12 |
| james_w | dvheumen: and to do it now you can use "touch .bzr/repository/no-working-trees" | 23:12 |
| james_w | "bzr remove-tree" will remove any existing working trees that you don't want. | 23:12 |
| dvheumen | james_w: I already found out about that command, that wasn't the problem... it's just that new branches would still have trees | 23:13 |
| dvheumen | james_w: should I report the bug as a missing feature for 'bzr reconfigure'? | 23:14 |
| dvheumen | or should I just say 'Can't convert repository to treeless repository' (in a few more words) | 23:15 |
| james_w | yes please, I've been looking for somewhere to put that function and reconfigure seems like the best place | 23:15 |
| james_w | well, if you just report the latter I'll follow up and recommend the former. | 23:15 |
| ryanakca | jelmer: untill I get to upgrade, any other workarounds? "bzr --no-plugins init" gives ``bzr: ERROR: No repository present: "file:///home/ryan/work/kubuntu-startpage-mockup/"'' | 23:17 |
| jelmer | ryanakca: Is there perhaps a .bzr directory in that location already? | 23:18 |
| dvheumen | james_w: Isn't this bug report about the same issue? https://bugs.launchpad.net/bzr/+bug/145033 | 23:18 |
| ubottu | Launchpad bug 145033 in bzr "need a command to switch a repository between trees and no-trees" [Medium,Triaged] | 23:18 |
| ryanakca | jelmer: oops, thanks | 23:18 |
| dvheumen | okay, so on second thought I won't report :P | 23:19 |
| dvheumen | btw, could you explain what 'triaged' means exactly? ('cause I've only got a faint clue at the moment) | 23:19 |
| james_w | dvheumen: hey, yes it is, thanks. | 23:21 |
| james_w | triaged is supposed to mean "enough information that a developer can start work on it" | 23:22 |
| dvheumen | ah right, okay, tnx guys :D | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!