=== _thumper_ is now known as thumper
[11:13] <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:14] <sparkiegeek> can anyone offer some insight/help?
[11:15] <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:16] <fullermd> Maybe I'm thinking of something else.
[11:16] <sparkiegeek> hmm, that would make sense, I did attempt to do that
[11:17] <fullermd> Mmm.  In a simple test here, the problem I'm thinking of is actually blowup on unshelve, not shelve.
[11:18] <fullermd> What's stat say before you try that?
[11:21] <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:24] <fullermd> Mmm.  Does it fail if you try shelving only the patch_302?
[11:27] <sparkiegeek> fullermd: it does, with a slightly different error: http://paste.ubuntu.com/9745514/
[11:28]  * sparkiegeek tries shelving just the files in the directory
[11:29] <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:30] <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:31] <fullermd> All seem not really related to your initial...
[11:32] <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:33] <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:35] <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:38] <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:39]  * 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:40] <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:42] <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
[22:01] <mark06> hi all, I need your support on this https://lists.archlinux.org/pipermail/pacman-dev/2015-January/019798.html
[22:02] <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:05] <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:07] <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:20] <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:21] <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:24] <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:25] <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:26] <mark06> they intend to fix this with artificial, buggy checks to know whether "B is a branch of X/A"
[23:46] <fullermd> I don't see how you can, programmatically.  That's a social question, and it's all kinds of fuzzy.
[23:47] <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:48] <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.