| === _thumper_ is now known as thumper | ||
| sparkiegeek | hi, I just got a scary traceback from bzr when trying to shelve some changes. First attempt was a selective shelve, but can reproduce it with a blanket shelve: | 11:13 |
|---|---|---|
| sparkiegeek | http://paste.ubuntu.com/9745307/ | 11:13 |
| sparkiegeek | can anyone offer some insight/help? | 11:14 |
| sparkiegeek | (I have previously bzr shelve'd just fine on this branch) | 11:15 |
| fullermd | Seems like I've heard of such things when there are directories being shelved... | 11:15 |
| fullermd | Maybe I'm thinking of something else. | 11:16 |
| sparkiegeek | hmm, that would make sense, I did attempt to do that | 11:16 |
| fullermd | Mmm. In a simple test here, the problem I'm thinking of is actually blowup on unshelve, not shelve. | 11:17 |
| fullermd | What's stat say before you try that? | 11:18 |
| sparkiegeek | http://paste.ubuntu.com/9745431/ | 11:21 |
| sparkiegeek | (names changed to protect the innocent) | 11:21 |
| sparkiegeek | patch_302 is the directory that I attempted to shelve (along with the files therein, and other related changes in other files) | 11:21 |
| fullermd | Mmm. Does it fail if you try shelving only the patch_302? | 11:24 |
| sparkiegeek | fullermd: it does, with a slightly different error: http://paste.ubuntu.com/9745514/ | 11:27 |
| * sparkiegeek tries shelving just the files in the directory | 11:28 | |
| sparkiegeek | eek | 11:29 |
| sparkiegeek | so I tried the shelve, just selecting the files, then rm'd and bzr rm'd the directory. THen tried to unshelve | 11:29 |
| sparkiegeek | http://paste.ubuntu.com/9745550/ | 11:29 |
| fullermd | OK, yeah, well that first at least is expected; you're trying to shelve the dir, but not the files in it. It should fail with a better message, but at least failure is expected. | 11:30 |
| fullermd | The second, also, trying to unshelve files into a dir it no longer knows about, bad juju. | 11:30 |
| fullermd | All seem not really related to your initial... | 11:31 |
| sparkiegeek | so if I were to "unwind" my actions properly by doing something like: bzr shelve $FILES; bzr rm $DIR; rm -f $DIR; <stuff>; mkdir $DIR; bzr add $DIR; bzr unshelve | 11:32 |
| sparkiegeek | would you expect that to work? | 11:32 |
| fullermd | I'd tend to think not, since that second add would be a different dir from bzr's perspective (independent add == different file-id)... | 11:33 |
| sparkiegeek | ok | 11:33 |
| fullermd | I can't reproduce your initial. I note that it sorts differently than those names actually do, so your real file/dir names are in a different order than those standins. | 11:35 |
| fullermd | Which could be significant; there have been occasional ordering-dependant issues in these sort of things. | 11:35 |
| sparkiegeek | oh, I was just bad at censoring and retaining information | 11:38 |
| sparkiegeek | the stat output is ordered as I expect (alphabetically, within the added: and modified: groups) | 11:38 |
| * fullermd nods. | 11:39 | |
| fullermd | Which suggests it could be something ordering dependant. | 11:39 |
| fullermd | (which I don't reproduce here, since I get ordering consistent with those censored names) | 11:39 |
| fullermd | Try putting together a simple test case with standin files, ordered as yours are; if we can reproduce it easily, it's probably fixable. | 11:40 |
| sparkiegeek | ok, will try to do so | 11:42 |
| fullermd | I can't do any more experimenting with it right now, sorry. I need to get to sleep, the sun's about to come up 8-} | 11:42 |
| sparkiegeek | :) | 11:42 |
| sparkiegeek | fullermd: thanks for your help | 11:42 |
| mark06 | hi all, I need your support on this https://lists.archlinux.org/pipermail/pacman-dev/2015-January/019798.html | 22:01 |
| mark06 | tldr: no artificial check is needed to know that branch x is not a clone of y, because when we bzr pull from y into x, it would fail _anyway_, is this true? | 22:02 |
| fullermd | If x is not a strict subset of y, then "cd x ; bzr pull y" will fail without changing anything, yes. | 22:05 |
| fullermd | I'm not sure whether "clone" is important to the case; clone is more a mechanism of "how we got x", whereas pull will succeed fail based on "what x currently has". | 22:05 |
| fullermd | It wouldn't help in the case that you really want to check "y is where x came from". | 22:07 |
| fullermd | So if you're trying to guard against the case "x is really supposed to be tracking z, but currently is coincidentally a subset of y, but we really don't want to pull y over it", just doing a pull will put you in a bind. | 22:07 |
| mark06 | not sure if I understand you but "is a clone" means it's "the same" repository, but missing updates, then we update with bzr pull | 22:20 |
| mark06 | here is the origin of the problem https://projects.archlinux.org/pacman.git/commit/?id=c926c39 | 22:21 |
| mark06 | then later bzr support was added by simply copying that kind of code | 22:21 |
| mark06 | how about the following problem: we branch A from web into local dir B, we later want to update B from A but for some reason bzr pull will fetch from X instead of B | 22:24 |
| mark06 | it happens to be that X is a fork of A and contains all commits of B | 22:25 |
| mark06 | result: bzr pull will succeed, but we wanted to pull from A not X, how to fix this? | 22:25 |
| mark06 | they intend to fix this with artificial, buggy checks to know whether "B is a branch of X/A" | 22:26 |
| fullermd | I don't see how you can, programmatically. That's a social question, and it's all kinds of fuzzy. | 23:46 |
| fullermd | Comparing URL's gets you somewhere. Normalizing and comparing gets you further. | 23:47 |
| fullermd | But there can totally be multiple paths that wind up the same place. The server can have multiple names. There can be http vs bzr+ssh vs sftp access. There can be multiple socially-identical mirrors in play. And on and on... | 23:47 |
| fullermd | Comparing normalized URL's would catch a lot of the simple cases, and maybe that's good enough for the use-case in question. But it's always gonna just be a guess. | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!