| poolie | hi all | 00:02 |
|---|---|---|
| spiv | Hi poolie. | 00:02 |
| poolie | hi there spiv | 00:12 |
| mhall119 | is there anything for bzr like hg subrepos? | 01:37 |
| poolie | i think you want 'bzr scmproj' | 01:43 |
| poolie | http://doc.bazaar.canonical.com/plugins/en/scmproj-plugin.html | 01:43 |
| AfC | jelmer: following from our conversation yesterday... is there supposed to be newer version of bzr-git in the https://launchpad.net/~bzr/+archive/ppa PPA? | 02:50 |
| poolie | sipv, do you understand what bug 692829 is asking about? | 03:28 |
| ubot5 | Launchpad bug 692829 in Bazaar "Once binary files modified, status-undo does not work." [Undecided,Incomplete] https://launchpad.net/bugs/692829 | 03:28 |
| poolie | hi afc | 03:28 |
| AfC | poolie: Hello Martin | 03:29 |
| spiv | poolie: it appears they are saying that doing 'bzr st' while the file is open in Excel causes the file to marked as modified. | 03:30 |
| spiv | poolie: which seems pretty weird and unlikely to me, but probably easy for someone with Windows + Excel to confirm or not. | 03:30 |
| poolie | i wouldn't be at all surprised if excel does autosave the file or something | 03:30 |
| spiv | Yeah. My suspicion is there are factors like that they aren't taking into account. | 03:31 |
| spiv | Unfortunately we don't have 'bzr diff --format=hex'. Hmm... | 03:32 |
| poolie | wbn | 03:32 |
| * spiv files a bug | 03:36 | |
| poolie | i'll read vila's patch, then yours | 03:38 |
| poolie | in the hope you can submit before xmas | 03:38 |
| spiv | Thanks! | 03:40 |
| poolie | spiv i think i like the abstract search result concept | 05:31 |
| spiv | Yay :) | 05:33 |
| spiv | I'm just in the middle of seeing if has much impact on the time to branch or update lp:emacs | 05:33 |
| spiv | So far it looks good, but I'm still waiting for the full repo to download. | 05:34 |
| spiv | (Not a metric download speeds: progress spinner bouncing from ~50kB/s up to 1650kB/s, but mainly in the 150kB/s to 500kB/s range) | 05:35 |
| spiv | The get_stream request for all the emacs tags + tip is only 11k. | 05:35 |
| poolie | ok, one reviewed | 05:53 |
| poolie | spiv do you want to talk about, or get review on, any aspect in particular? | 06:02 |
| spiv | poolie: the main thing I would ask for is a review of https://code.launchpad.net/~spiv/bzr/fetch-tags-from-non-sprout-too/+merge/42911, but you already did that :) | 06:14 |
| spiv | I guess the big question in my mind is naming. | 06:15 |
| spiv | I think it's partly that graph.SearchResult is being used in multiple contexts. | 06:15 |
| poolie | oh, what are they? | 06:16 |
| spiv | Sometimes it is literally the result of a breadth-first search of a graph. Sometimes it is an instruction to something to perform/replicate that search. | 06:16 |
| spiv | So sometimes it feels natural to call it a "search result" and other times it feels natural to call it a "search" or a "recipe" or something like that. | 06:16 |
| poolie | so there are some interfaces that want to take an object that can provide a list of revisions | 06:16 |
| poolie | and in some cases it's already been evaluated, and in others it won't be | 06:17 |
| poolie | is it actually desirable that they're treated the same way? | 06:17 |
| spiv | That can find a set of revisions when applied to a repo, possibly with sanity checks on what is expected. | 06:17 |
| poolie | would it be better perhaps if we were clear about when it's evaluated? | 06:17 |
| spiv | (SearchResult recipes include the number of keys that should be found so the recipient can know that it has found the same set, but e.g. PendingAncestryResults don't mind if there are ghosts.) | 06:18 |
| spiv | "when it is evaluated" might be the key question. | 06:19 |
| poolie | it reminds me a bit of the questions about storage in lp | 06:19 |
| poolie | objects that evaluate on demand can make performance harder to control | 06:19 |
| spiv | Or to answer your question more directly: I think I'd probably be happier if we were clear about that :) | 06:20 |
| spiv | Right. | 06:20 |
| poolie | :) | 06:20 |
| spiv | We want to be fairly explicit with these I think. We use these things pretty consciously on the network because e.g. they are more compact than a simple list of revision ids, and also some avoid the need to walk lots of the remote graph before making a request. | 06:21 |
| poolie | right, so passing a more abstract description across the network makes sense | 06:23 |
| poolie | a NotInOther type search doesn't seem immediately possible to serialize though? | 06:23 |
| spiv | right | 06:24 |
| poolie | so that would be done... locally on the client, by interrogating the remote? | 06:25 |
| poolie | or perhaps better by sending across to the remote server just our tip revision, or a summary of some well-spaced revisions that we already have? | 06:26 |
| spiv | So the interface I currently have for that kind of object is simply that it has a get_search_result method (which in turn calls search_missing_revision_ids which does the breadth-first search etc). I don't think the NotInOther objects buy us much practical benefit at the moment. | 06:26 |
| spiv | They mainly exist because it was the natural way to refactor the existing code, which defers that search until the middle of fetch.py | 06:27 |
| spiv | And so these objects exist as a way for a caller to say "When you finally start fetching, you need to perform this search"... I don't know if that's useful compared to requiring callers to just perform that search immediately, except that this is arguably a more convenient API to use than grabbing an InterRepo and invoking search_missing_revision_ids. | 06:28 |
| poolie | so that is to say that some callers | 06:28 |
| poolie | don't particularly want the search to be lazy | 06:29 |
| poolie | but they don't really care to ask for it to be done themselves either? | 06:29 |
| spiv | As for how NotInOther searches are resolved: I agree, in principle we can do it more efficiently than we currently do, but that's a separate problem probably. | 06:29 |
| spiv | Yes, I think that's right. | 06:29 |
| mxc | hi | 06:30 |
| spiv | Also, my suspicion is that seeing these objects in a call stack or their repr in a .bzr.log is probably more informative than the result of the search. | 06:30 |
| spiv | As it describes what the caller wanted, rather than just what was found. | 06:31 |
| poolie | that's probably true | 06:31 |
| poolie | though you can still get that if you distinguish the search from its result | 06:31 |
| poolie | just by making the resultset-like-thing remember its origin | 06:31 |
| poolie | even if only for human consumption | 06:31 |
| spiv | That's true. | 06:31 |
| poolie | that can be useful in db-type resultsets | 06:32 |
| spiv | Hi mxc | 06:32 |
| poolie | hi | 06:32 |
| poolie | spiv, so that's the main conceptual-type feedback i have | 06:33 |
| poolie | my experience with other things in bzr leads me to feel it's pretty important to have exactly one name for a concept from the beginning | 06:34 |
| poolie | thus the point about aligning the parameter and object names | 06:34 |
| spiv | Yes, I agree. | 06:35 |
| spiv | Hmm. So "Search" and "SearchResult" seem like reasonable names. If we allow fetch to receive either kind, what to call the union? | 06:37 |
| spiv | Thanks, I'll sleep on it and review this conversation and hopefully come up with a clear answer :) | 06:38 |
| poolie | i haven't dug into it as much as you of course | 06:38 |
| poolie | i would be inclined to say fetch only takes the result | 06:39 |
| poolie | and the caller must do, say | 06:39 |
| poolie | .fetch(spec=search.execute()) | 06:39 |
| poolie | or something like that | 06:40 |
| poolie | that doesn't seem too onerous | 06:40 |
| spiv | I agree, that seems reasonable to me. | 06:40 |
| spiv | If it turns out to be too onerous... we can always change the API again later ;) | 06:40 |
| * spiv steps afk for a bit | 06:41 | |
| poolie | perhaps to make it easier for callers we should have some unbound functions that create the right interrepo and call methods on it | 06:41 |
| poolie | but that's a bit separate | 06:41 |
| Anteru | Hi | 07:23 |
| Anteru | I have a Bzr repository converted from SVN with some issues. For one, it has ghost revisions referenced which don't work well with QBzr right now, and the other problem is some commits were done without proper bzr whoami information. Where should I start to write a filter to replay the whole repository history and clean it up? | 07:25 |
| Anteru | bzr-rewrite, or is there something else? Basically I want to change some author names and remove references to ghost revisions, while keeping the history intact as much as possible. | 07:25 |
| spiv | There's also bzr-fastimport | 07:41 |
| spiv | But both options will modify the history in ways that will stop merges from branches from the pre-filtered history working with the new history. | 07:42 |
| spiv | (I'm not sure exactly how strictly you mean "intact") | 07:43 |
| === mxc_ is now known as mxc | ||
| vila | hi all ! | 07:49 |
| vila | poolie: thanks for your review ! I've replied | 07:49 |
| Anteru | That's ok, I'm fine if all clients have to branch again. | 07:55 |
| Anteru | I just want to keep the individual commits in the history if possible, in case I want to revert one. | 07:55 |
| Anteru | Basically, my plan is that all developers push their changes, the repository gets locked down, I run the filter and all developers branch from scratch. | 07:56 |
| Anteru | However, I want to rescue as much of the history as possible; i.e. loosing everything is not an option. | 07:57 |
| poolie | Anteru: then i think either of the things spiv suggests will work | 08:34 |
| poolie | hi vila (i'm not really here) | 08:34 |
| vila | poolie: hey, no problem, just say the magic word :) | 08:34 |
| Anteru | poolie: thanks; I'll give it a shot then. I thought that one might be better suited than the other. | 08:34 |
| poolie | i would probably start with rewrite | 08:35 |
| johnf | I've been asked to create a set of files which describe the changes made to the code base at each commit. For the most part I can use "bzr diff -c REVNO", except when merges occur. Then things get more complicated. for a merge with no conflicts, I'd really like to see an empty diff and if there were conflicts I'd love to just see the changes that solved the conflict. Anyone have any pointers on where to start or if this is | 08:47 |
| spiv | johnf: your question got a little truncated | 08:48 |
| spiv | (at "if this is") | 08:48 |
| johnf | even possible? | 08:48 |
| spiv | but basically bzr stores tree states, so to answer "was this a merge with no manual conflict resolution", then the totally pedantic answer is you can't. | 08:49 |
| lifeless | difftacular | 08:49 |
| spiv | A more practical and almost correct answer is "redo the merge, and see if bzr's automatic output matches what was committed" | 08:49 |
| spiv | Oh right, abentley's thing. | 08:50 |
| lifeless | which is what launchpad uses to answer an extremely similar quesiton | 08:50 |
| spiv | (https://launchpad.net/difftacular, in case you hadn't guessed) | 08:50 |
| johnf | lifeless: So I've had a look at difftacular and can't seem to make it do something sensible. Let me have another crack and then come back | 08:50 |
| poolie | aaron would probably like to hear what goes wrong | 08:53 |
| ThiasG | Good morning from Germany... | 08:54 |
| spiv | Good evening from Australia. | 08:54 |
| ThiasG | I have a question about implementing an access control plugin on the server side of a bzr+ssh connection. | 08:55 |
| ThiasG | I found, that mainly the pre_open and the pre_change_branch_tip hooks triggers, so that I'm not able to get a hook for remove-branch and other commands, I want to restrict on the server side. | 08:57 |
| spiv | ThiasG: I'm about to leave for the night, but maybe https://lists.ubuntu.com/archives/bazaar/2010q1/066623.html and http://bazaar.launchpad.net/%7Ebzr-pqm/bzr/bzr.dev/annotate/head%3A/contrib/bzr_ssh_path_limiter help. | 08:58 |
| spiv | Ah, right. | 08:58 |
| spiv | ThiasG: unfortunately remove-branch would be implemented in terms of the "VFS" operations of the bzr+ssh conneciton | 08:59 |
| spiv | ThiasG: i.e. the client simply saying "please delete these files and delete this directory" | 08:59 |
| spiv | ThiasG: you *could* hook that by overriding the VFS HPSS requests, see the registry of request handlers in bzrlib.smart.request | 09:00 |
| ThiasG | would it be enough to "overwrite" the cmd_serve class and decorate the transport? Or do I need to get down to the VFS? | 09:00 |
| spiv | Or alternatively, and probably more robustly, by implementing a custom transport | 09:00 |
| spiv | Right, I'd decorate the transport. | 09:00 |
| ThiasG | That would be a long chain of classes I would have to extend in the registry for accessing the VFS. | 09:00 |
| spiv | It's probably enough to reject any delete of a file in */.bzr/branch/* with PermissionDenied | 09:01 |
| spiv | (But allow put_file* to replace existing files) | 09:01 |
| ThiasG | Okay, Good idea. | 09:01 |
| spiv | To be pedantic you'd also want to intercept renames of those files to some random location | 09:01 |
| ThiasG | I give it a try. | 09:01 |
| poolie | ok, good night all | 09:02 |
| ThiasG | Good night... | 09:02 |
| spiv | e.g. renaming the branch and all it's files to garbage-1234 would effectively remove the branch, at least in the sense that other clients can't access it. | 09:02 |
| ThiasG | ;-) | 09:02 |
| spiv | And of course if a client can't do "delete foo" but can do "rename foo bar; delete bar", then you haven't really restricted them :) | 09:03 |
| spiv | 'night poolie | 09:03 |
| ThiasG | Understood. | 09:03 |
| ThiasG | I had hoped, that I could operate on a higher level even on the server side :-( | 09:03 |
| spiv | We're slowly working on removing the need for the VFS operations. | 09:03 |
| ThiasG | Would wil replace the VFS operations? | 09:04 |
| spiv | But it's not a big priority, we've moved them out of the performance-critical operations already which was the main motivation. | 09:04 |
| spiv | The main motivation for removing them entirely is exactly what you're talking about: writing nice access control stuff. | 09:04 |
| spiv | I have to go now; hopefully someone else here can keep answering your questions, otherwise try the mailing list, I'll be happy to reply there. | 09:05 |
| ThiasG | Are there more hooks on the server side planned? | 09:05 |
| spiv | Not planned, precisely: please file bugs for hooks you'd like to see though! | 09:06 |
| ThiasG | Okay, thank you very much. | 09:06 |
| spiv | Some may be easy for us to implement already | 09:06 |
| spiv | So we'll happily do that. | 09:06 |
| ThiasG | Have a good evening :-) | 09:06 |
| spiv | Others may take more work (like providing non-VFS requests in the protocol for operations that are only possible via the VFS requests currently) | 09:06 |
| spiv | Thanks :) | 09:06 |
| ThiasG | I would be grate to have a server hook as equivalent to the smartclient call hook... | 09:07 |
| spiv | ThiasG: hmm, good idea, and should be easy to implement, please file a bug | 09:34 |
| spiv | (if you haven't already!) | 09:35 |
| ThiasG | I will do it. | 09:39 |
| ThiasG | See https://bugs.launchpad.net/bzr/+bug/692912 | 09:44 |
| ubot5 | Ubuntu bug 692912 in Bazaar "smartserver call hook" [Undecided,New] | 09:44 |
| === lifeless_ is now known as lifeless | ||
| === frakturfreak__ is now known as frakturfreak | ||
| === _thumper_ is now known as thumper | ||
| === jelmer__ is now known as jelmer | ||
| ThiasG | I try to write a server side plugin/hook for acl (using bzr+ssh). In the moment I have the base of a branch in the format filtered-3079697228:///home/thiasg/testrepo/trunk/ and I want to get the path relative to the bzr serve directory. How to I get this? | 13:16 |
| vila | ThiasG: I don't have much experience in this area but presumably the bzr server directory was '/' in this case | 13:20 |
| vila | ThiasG: did you look at the scripts in the contrib dir ? | 13:20 |
| vila | ThiasG: bzr_acees and bzr_ssh_path_limiter | 13:20 |
| vila | access | 13:20 |
| ThiasG | The are only handling acces for the whole server at once. In the moment I want to prevent the rmbranch command for all people. Then there are repo's on the server with restricted write access. | 13:22 |
| ThiasG | Also we plan to allow some people to commit on a branch, but not change anything else. Then someone else could merge this change to the trunk. | 13:22 |
| vila | ThiasG: I realize that, just mentioning that path based controls and command controls are different | 13:23 |
| vila | ThiasG: bzr serve runes in a chroot'ed env too so from inside the server you're not supposed to access things outside of it | 13:24 |
| vila | ThiasG: so trying to control the real path at the command level... is problematic | 13:24 |
| vila | s/outside of it/outside of the chroot/ | 13:25 |
| ThiasG | My thought was to have a confguration file at a specific place, in which the access policy is defined. This would be the thing, which needs to be read outside. | 13:26 |
| ThiasG | But I need the paths in a way, that they are compareable to the format of the configuration file, which is not yet defined. | 13:26 |
| vila | ThiasG: I presume that the filtered:// paths are inside the chroot so in fact, relative to the root, you can use the same convention in your config file | 13:28 |
| ThiasG | okay | 13:28 |
| vila | check my assumption by running 'bzr serve /home/thiasg' instead of 'bzr serve /' and see what filtered:// paths you get | 13:29 |
| vila | ThiasG: out of curiosity, why do you want to forbid rmbranch (assuming people can still create or move their branches around) ? | 13:30 |
| ThiasG | What is the best way, to trigger this from the client side? I'm not using the ssh command option on this account, because otherwise I'm not able to access the unix machine anymore... | 13:30 |
| ThiasG | Yesterday someone remove the trunk branch. I want to avoid this. | 13:31 |
| vila | hmpf | 13:31 |
| ThiasG | From my old CVS time, we had triggers in place for preventing changes to certain tags (e.g. release tags) and branches (release bugfix branches) | 13:32 |
| vila | trigger what ? not using the ssh option ? Do you mean you're using a bzr server directly with bzr:// urls ? | 13:32 |
| ThiasG | In CVS they are called triggers. For bzr we are using ssh with the bzr_access script. | 13:33 |
| vila | ha, you're already using bzr_access, ok | 13:33 |
| vila | ThiasG: very roughly triggers are hooks in bzr | 13:34 |
| vila | ThiasG: but we are adding them as the need arise, so obviously not all of them exist yet | 13:35 |
| ThiasG | But it is not really helpful. Mainly you are able to give no access, read access or write access to all repos. This is already possible with bzr_ssh_path_limiter. | 13:35 |
| vila | patches welcome :-} | 13:37 |
| ThiasG | I tried the bzr branch hook for getting info about the branch and the repo. The alternative approach is the get_command hook for getting access to the cmd_serve command and wrap the transport, which I'm focusing in the moment. | 13:37 |
| ThiasG | It is not possible directly from bzr_access. | 13:38 |
| AfC | When you use --fixes, do you do that only on the commit where you think you fixed it, or do you have to do it on every merge up the chain? | 13:58 |
| jelmer__ | hi AfC | 14:00 |
| AfC | jelmer__: hello Jelmer | 14:00 |
| jelmer__ | AfC: To answer your question earlier, the PPA I meant was http://launchpad.net/~bzr/+archive/daily | 14:00 |
| vila | AfC: only on the commit where you fixed the bug | 14:00 |
| AfC | jelmer__: ah | 14:00 |
| AfC | vila: that's what I expected & hoped. Thanks. | 14:00 |
| vila | AfC: also, I sometimes forgot to use it so I just use it later in one of the merges | 14:01 |
| vila | AfC: It's a project policy thing I'd say | 14:01 |
| AfC | jelmer__: will that promote into ppa soon, or, do I really need to be using the dailies if I'm working with a Git upstream? | 14:01 |
| AfC | vila: sure | 14:01 |
| AfC | vila: well, we don't really depend on if for workflow; I am just trying to Do The Right Thing™ for future purposes. | 14:02 |
| jelmer__ | AfC: I'd recommend the daily builds, the PPA only has releases afaik | 14:04 |
| vila | jelmer__: hi ! | 14:08 |
| vila | jelmer__: no news for this weird failures on the bzr daily build ? | 14:08 |
| jelmer__ | vila: hey! | 14:08 |
| vila | jelmer__: no pressure intended | 14:08 |
| vila | err, no really I mean it :) | 14:09 |
| jelmer__ | :-) | 14:09 |
| jelmer__ | vila: it's on my list of things to look into | 14:09 |
| vila | bah, the more I'll repeat it the more you're likely to think I'm ironic :) | 14:09 |
| vila | ok, np | 14:09 |
| AfC | jelmer__: really? Dailies are safe to use? | 14:09 |
| vila | I' thought it was testtools related and the build seem to use > 0.9.8 so... | 14:10 |
| vila | AfC: you tell us ! | 14:10 |
| vila | kidding | 14:10 |
| AfC | vila: I think you know what I'm asking :) | 14:10 |
| jelmer__ | AfC: Well, you can never be too careful. That said, the daily builds require the full test suite to pass for a package and that says a lot. | 14:10 |
| AfC | ie, are people just throwing it over the wall at that PPA | 14:11 |
| AfC | or are you really expecting people to use it? | 14:11 |
| vila | AfC: yup, they should be as safe as our test suites can be trusted (and we trust them quite a lot) | 14:11 |
| AfC | In the past bzr.dev was NOT usable by anyone other than Bazaar hackers | 14:11 |
| jelmer__ | AfC: These packages are thrown over the wall by Launchpad (there are no people involved) | 14:11 |
| AfC | and that was project policy (as much as such things exist, given these are all really just social conventions) | 14:11 |
| vila | we are running more plugin test suites these days so it can still fail but we'll know earlier | 14:11 |
| AfC | Cool | 14:12 |
| vila | and knowing earlier *should* mean we'll fix them earlier too | 14:12 |
| AfC | In Theory™ | 14:12 |
| AfC | :) | 14:12 |
| vila | hehe yeah | 14:12 |
| vila | but at least using a PPA means you can avoid some problems with plugins being out-of-date | 14:13 |
| vila | and get fixes as soon as they appear on their respective trunks | 14:13 |
| vila | that being said, the failures we know about today seem to be mostly test-only issues | 14:14 |
| vila | unles jelmer__ knows better ;) | 14:14 |
| vila | ss | 14:15 |
| vila | socially the main difference is that we get mails when they occur during the builds rather when some innocent user encounter bugs (in Theory ;) | 14:16 |
| === beuno_ is now known as beuno | ||
| === zyga is now known as zyga-food | ||
| === knitt1 is now known as knittl | ||
| ThiasG | vila: I did the first prototype to achieve, what I want for my purpose of ACLs. Configuration is missing, but will follow soon. It is not nice, but seems to work. See http://bzr.openpetra.org:8008/bzr-accesscontrol/trunk | 15:35 |
| mhall119 | does anybody know of a bzr plugin that is similar to mercurial's subrepos? | 15:43 |
| mhall119 | or anything that will allow me to link other branches to paths in my branch | 15:43 |
| rjek | bzr branch; bzr join | 15:44 |
| rjek | (then bzr merge url://to/imported/branch to update.) | 15:45 |
| mhall119 | but that consumes the other tree, right? | 15:45 |
| mhall119 | meaning it's no longer separate | 15:45 |
| rjek | Not sure I understand what you mean. | 15:46 |
| mhall119 | okay, say I have BranchA | 15:46 |
| mhall119 | and BranchB | 15:46 |
| mhall119 | I want BranchA/subdir to contain BranchB at revision 1 | 15:47 |
| mhall119 | so when I bzr branch BranchA, it will also bzr branch BranchB into ./subdir | 15:47 |
| rjek | bzr branch -r1 url://to/branchb subdir; bzr join subdir | 15:47 |
| mhall119 | and then later, when someone's done work on BranchB's trunk, I can update BranchA to use revision 2 of BranchB | 15:47 |
| rjek | bzr merge | 15:48 |
| mhall119 | right, but then subdir is no longer associated with BranchB | 15:48 |
| rjek | Sure it is; you can merge the changes. | 15:48 |
| rjek | I do this all the time, where branchb is from svn. | 15:49 |
| mhall119 | but I can't "cd subdir; bzr pull url://to/BranchB" | 15:49 |
| rjek | bzr branch svn://foo/bar; bzr join bar; <time passes>; cd bar; bzr merge svn://foo/bar; # pulls updates from upstream svn | 15:49 |
| rjek | I have no idea if that's the "proper" way, but it works a treat. | 15:50 |
| mhall119 | I think that only works because SVN manages each directory on it's own | 15:50 |
| mhall119 | doing it with 2 bzr branches, I get: bzr: ERROR: These branches have diverged. | 15:51 |
| mhall119 | oh wait, I see what it's doing.... | 15:52 |
| vila | mhall119: use merge not pull, what you won't be able to do with this scheme though, is to make modifications in branchb and push them back to their origin | 15:52 |
| bac | Hi, a colleague has a large codebase on a server that is not yet in bzr. There is an exact duplicate on a local machine fetched via ftp. We'd like to start using bzr but, due to size and slow connection, would like to use the existing code directories to become related without having to do a complete 'bzr branch' from the server. possible? | 15:52 |
| rjek | vila: He never asked for that, so there should be no problem :) | 15:52 |
| mhall119 | so, it's not a separate repo, but it has the old repo's history, so merging may still work | 15:52 |
| vila | rjek: hehe | 15:53 |
| mhall119 | yeah, not being able to make changes to branchb isn't ideal | 15:53 |
| bac | abentley: ^^ ? | 15:53 |
| rjek | mhall119: You've changed your specification! :) | 15:54 |
| vila | there are plugins that try to address the lack of proper nested trees support in bzr : scmproj and externals (?) | 15:54 |
| mhall119 | rjek: not really, as hg subrepos lets you change branchb, and my original spec was something like subrepos | 15:54 |
| vila | bac: duplicate of what ? a bzr repo ? | 15:54 |
| mhall119 | so, it's more clarifying my specification | 15:54 |
| bac | vila: neither the code base on the server nor the local copy are bzr repos yet | 15:55 |
| abentley | bac, I don't understand. Didn't you say the code was not yet in bzr? | 15:55 |
| vila | what are they then ? | 15:55 |
| bac | abentley: it is not but i would like it to be | 15:55 |
| bac | abentley: but i'd like to avoid refetching the entire code base since a non-bzr copy already exists | 15:55 |
| abentley | bac, when you fetch, you're fetching the revision history, which includes the file contents but is more than that. | 15:57 |
| abentley | bac, two branches cannot be related if they don't share revision history. | 15:57 |
| bac | abentley: i understand. i guess i'm asking is there a way to cheat, to only fetch the revision history and not the code | 15:57 |
| abentley | bac, You can tar up the .bzr directory, if you just don't want to use bzr for the transfer. | 15:57 |
| abentley | bac, we don't fetch the code. | 15:58 |
| abentley | bac, when you fetch the revision history, you don't necessarily end up with local copies of the source files. | 15:59 |
| abentley | bac, and if you do, those come from your local copy of revision history, so it's fast anyhow. | 15:59 |
| === beuno is now known as beuno-lunch | ||
| bac | abentley: sure. i was hoping there was a way to make repos on either side and fool them into thinking there was an ancestor relationship for bootstrapping | 16:00 |
| === zyga-food is now known as zyga | ||
| abentley | bac, you can make a stacked branch, but then you wouldn't be able to commit to it. And that would still download a lot. | 16:03 |
| abentley | bac, if the remote code was in svn, git or hg and you imported it into bzr using bzr-(svn|git|hg), you could do the same locally and the output would be compatible. | 16:08 |
| abentley | bac, but in general, if you want two branches to share revision history, you have to copy the revision history. | 16:09 |
| bac | abentley, ok, thanks | 16:10 |
| === deryck is now known as deryck[lunch] | ||
| === beuno-lunch is now known as beuno | ||
| === deryck[lunch] is now known as deryck | ||
| === jelmer__ is now known as jelmer | ||
| === joey is now known as rubberducky | ||
| === rubberducky is now known as joey | ||
| poolie | hi | 21:41 |
| jelmer | 'morning poolie | 21:42 |
| poolie | hi | 21:43 |
| s1aden | if an strace of bzr is hanging at: "bzr message 3 (bzr 1.6)\n\0\0\0\34d16:" | 22:11 |
| s1aden | what does that likely mean? | 22:12 |
| === s1aden is now known as sladen | ||
| jelmer | spiv: ^ | 22:20 |
| sladen | jelmer: spiv: I got straces, it appears be some firewalling issue from lanthanum->*.lp.net again. I've reopned it in RT | 23:32 |
| poolie | sladen: hi, yes, it looks like it's failing to start an ssh or tcp connection | 23:33 |
| poolie | that's the magic number at the start, as you might expect | 23:33 |
| poolie | sladen: still here? | 23:33 |
| sladen | poolie: yup | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!