[00:14] <poolie> hi all
[06:19] <vila> hi all !
[06:24] <mgz> morning vila!
[06:24] <vila> mgz: hey !
[06:24] <vila> mgz: I did comment on your mp but lp dropped my mail
[06:25] <vila> mgz: td;lr : please land whatever you can
[06:25] <vila> mgz: I share your curiosity about the consequences on pqm slowness
[06:25] <mgz> I will merge up to dev and see where I'm at.
[07:02] <vila> mgz: see my last comment on https://code.launchpad.net/~jelmer/bzr/config-file-permdenied/+merge/73361
[07:04] <mgz> vila: that branch should just land, but there does need to be a bug at least, and maybe a comment there
[07:05] <mgz> twas a comment, not a needsfixing
[07:05] <vila> mgz: can you file it and comment on the proposal ?
[07:05] <vila> yeah
[07:05] <vila> hmm
[07:06] <vila> mgz: is there an idiom we can use today that would avoid the mangling ?
[07:08] <vila> mgz: because this patch calls trace.warning twice, but the second call hides the path shuffling into a method that already contains a semi related FIXME (config.Store.external_url)
[07:08] <mgz> delay as long as possible, and keep the actual objects around to stringify when there's an output stream for them to go to
[07:08] <mgz> the logging module doesn't help much here
[07:09] <vila> hmm
[07:10] <vila> we are calling trace.warning to output *now*, so basically you're saying that trace itself should provide some way to encode the path/urls properly ?
[07:10] <mgz> but it's going to two places
[07:11] <vila> oh my, right
[07:11] <mgz> one, a file where we should (but don't really) enforce a utf-8 encoding
[07:11] <mgz> and (possibly) one to the console
[07:12] <vila> so what ? define and use .format() instead of '%' and inject some path/url specifier in the format string ?
[07:13] <vila> and will that be enough to cover cases where the fs encoding and the terminal encoding can't both provide a meaningful representation of the path ?
[07:14] <mgz> this is where knowing it's a path/url and not just some string is useful
[07:14] <mgz> because then you can percent-escape and get a correct reference
[07:15] <vila> percent-escape == url-encoded ?
[07:15] <mgz> if you've already stringified and just have the message to output, there's no safe transform you can do to get a correct path back again
[07:15] <vila> right, I agree that this is the root cause
[07:16] <vila> and I'm not amused by the fact that jelmer used 'utf8' instead of fs encoding either ;)
[07:17] <mgz> it's correct for the log, and his terminal :)
[07:23] <jam> morning all
[07:25] <jam> mgz: its correct for how the api of trace.note() and trace.warning() are currently defined.
[07:25] <mgz> which is a bug.
[07:25] <jam> mgz: I don't disagree, but it is not his place to fix it here
[07:26] <jam> I've *personally* decided not to focus on the issue, because I think if you really wanted to help windows users, you'd be better of polishing something like bzr-explorer
[07:26] <mgz> I don't think it is, but the line added will need changing when that bug is addressed.
[07:26] <jam> rather than trying to handle the 5-different possible-non-unicode encodings Windows has
[07:26] <jam> mgz: actually, if we just changed how trace.note/warning worked to have them write to the Windows Console Unicode api
[07:26] <jam> then utf-8 is just fine
[07:27] <jam> it can be trans-coded to UTF-16 losslessly
[07:27] <jam> which is where I'd *much* rather see the fix
[07:52] <vila> jam: hey !
[07:54] <vila> jam: ping
[07:54] <jam> vila: /wave
[07:55] <vila> jam: what exactly do you require to approve this safety net is brittle patch to be approved without delaying it for weeks ?
[07:57] <jam> vila: I thought I was clear about what I would like to see, a way to stop the test suite if a critical piece of infrastructure fails, that doesn't require us to kill the running process
[07:57] <jam> I'm willing to hedge on it that sys.exit is the best we can get
[07:58] <jam> it isn't playing nicely as a test suite, but it works fine for "bzr selftest"
[07:58] <vila> but you objected on using it
[07:58] <jam> vila " doesn't require killing the running process"
[07:58] <jam> that would be sys.exit()
[07:58] <jam> if someone uses another test runner, it will die on them which could be rather surprising.
[07:58] <vila> you objected on using sys.exit(), I removed it, you object again
[07:59] <jam> vila: #1) The original point is that we don't want 20k tests failing in the same way, right? Otherwise we would have left it at the status quo
[07:59] <jam> I'm not trying to go in circles. I do have a position I would like to see, all of the alternatives seem sub-optimal for different reasons
[07:59] <vila> doesn't apply to jelmer's case and for mthaddon's case we already have -1
[07:59] <jam> so I'm a bit ambivalent about picking one
[08:00] <vila> then let's land self.fail() and continue discussing 'FatalError' so we progress on both fronts
[08:00] <jam> vila: if it doesn't apply to either case then why do we have a patch?
[08:00] <jam> vila: good enough
[08:01] <vila> both cases are addressed: we get a meaningful error, mthaddon's case is less well addressed but also highly unusual
[08:03] <jam> vila: ISTR that jelmer was surprised to have so many tests failing, but sure
[08:04] <vila> I think jelmer (and I and mthaddon) were all confused because the error was masked and as such made the diagnosis hard
[08:04] <vila> the root of mthaddon case was: running as a user not declared in /etc/passwd. OMG ! How the hell do you end up in such a mess on a posix system ?
[08:05] <vila> the root of jelmer case was: you pretend to be root, yet, you don't have rights to even read files in your home dir. wtf ?
[08:07] <vila> jam: I totally see your point about FatalError, but we are playing tricks by handling a shared resource without telling the runner already, detangling that when a 10lines fix is available ? Worth the time ?
[08:08] <jam> vila: well, I was hoping it wouldn't be a lot of time by asking people who knew more about it. Unfortunately, one just got engaged and the other is going to have a baby RSN
[08:08] <vila> exactly
[08:09] <vila> so better separate the issues
[08:12] <vila> jam: do you mind voting on that proposal ?
[08:16] <jam> voted
[08:17] <jam> approve
[08:17] <Riddell> morning all
[08:17] <vila> jam: thanks !
[08:18] <jam> morning Riddell
[08:21] <vila> Riddell: _o/
[08:40] <poolie> hello europa
[08:41] <vila> poolie: hellllo AU :)
[08:41] <jam> ih eiloop
[08:41] <poolie> hi maj
[08:41] <jam> (i couldn't easily write it upside down, so I wrote it backwards)
[08:42] <vila> :)
[08:43] <fullermd> Hello Ganymede?
[09:06] <poolie> vila, re bug 837926
[09:06] <poolie> don't the subunit streams have enough data?
[09:08] <vila> poolie: only if you're the submitter
[09:09] <poolie> so this bug could be caused by logging the output?
[09:09] <poolie> *closed
[09:09] <vila> poolie: https://code.launchpad.net/~vila/bzr/837926-log-make-check/+merge/73492 is a simple and pragmatic way to address it
[09:10] <vila> poolie: I don't want to dive into solutions that requires modifying pqm or anything else, I just want a couple of `date` in the log files (which are already mirrored on chinstrap
[09:10] <poolie> if that's enough that's fine with me
[09:10] <poolie> hm
[09:17] <poolie> well, approved
[09:19] <vila> poolie: the '.bzr' invocation already redirects stderr, so I'm more comfortable with adding statements *around* its invocation that risking breaking it
[09:19] <vila> poolie: thanks for the review !
[09:19] <poolie> then time $(SHELL) -c './bzr ... '
[09:19] <poolie> but, ok, i see your point abotu risk
[09:20] <vila> poolie: re quoting, simple of double quotes ? (Can't remember which one is more likely to fail ;)
[09:22] <poolie> failing and non-failing quotes? :)
[09:23] <vila> bah, I'll just remove  the brackets and go with double ones ;)
[09:23] <poolie> it seems to all be rediceted already
[09:23] <poolie> also, i thought we got rid of the separate run in ascii mode?
[09:23] <poolie> did that come back? perhaps that accounts for the slow down
[09:24] <vila> poolie: only for 2.0
[09:24] <poolie> oh, i hadn't noticed this was into 2.0
[09:24] <poolie> though you do say so
[09:24] <vila> gone in 2.1
[09:24] <vila> 2.2 added subunit
[09:25] <poolie> i'm a bit skeptical about changing this in old series
[09:25] <vila> 2.3 added robustness
[09:25] <vila> poolie: I can start anywhere you want, I'm mostly interested by 2.3/2.4/trunk myself
[09:26] <poolie> so, changing this stuff has historically tended to throw up environment-dependent failures
[09:26] <poolie> therefore i wouldn't change it in a stable series without a really good reason
[09:27] <vila> right, me too,
[09:27] <poolie> what are you actually going to do with this?
[09:27] <vila> the effect should be seen when landing the patch itself, so either it works or it breaks
[09:27] <poolie> that hasn't always been true in the past
[09:28] <vila> sure, I don't mind starting at 2.4/trunk or even only trunk if you prefer
[09:29] <vila> the intent is to get timings and a poor-man's monitoring
[09:29] <poolie> i think just trunk
[09:29] <vila> ok
[09:30] <poolie> so are you hoping to find out that eg it's consistently slower, or it's very variable from one revision to the next, that sort of thing?
[09:31] <vila> yeah, I don't have any pre-conception
[09:43] <poolie> ok
[09:43] <poolie> so i wouldn't like to break anything just for kind of snooping-around investigation
[09:44] <poolie> sidnei sent me some tarmac/etc instructions which i hope to set up some time
[09:44] <vila> poolie: I'll stop and revert on first sign of an issue, I swear ;)
[09:58] <jam> vila: for the datestamp, would you want to use: `date "+%F %T"` ? It seems a bit easier to parse than just date
[10:01] <poolie> or date -I
[10:01] <poolie> sorry, -Isec
[10:01] <jam> that works, too
[10:02] <vila> jam: th... err, ok, we still have some time before pqm catches up ;)
[10:02] <jam> poolie: odd, 'man date' doesn't seem to report it, but 'date' supports it
[10:02] <vila> right, I was about to ask about portability :)
[10:02] <poolie> you have no mandate! i demand a new election.
[10:02] <fullermd> date: illegal option -- I
[10:02] <poolie> it is a gnu extension
[10:03] <vila> fullermd: does BSD use gnu date ?
[10:03] <vila> osx doesn't
[10:03] <Riddell> is there an equivalent in python of  isinstance(foo, function) ?
[10:03] <poolie> is it a function?
[10:04] <ccxCZ> you have callable()
[10:04] <poolie> probably you want 'callable(foo)'
[10:04] <jam> Riddell: do you want something like callable() ? which has been deprecated
[10:04] <fullermd> Of course not!  We ain't lettin' no commie control something as important as time!
[10:04] <poolie> :)
[10:04] <jam> note that a Class that implements __call__ is 'callable()'
[10:04] <jam> well, an object ...
[10:05] <poolie> so it depends on exactyl what you meaon
[10:05] <poolie> anyhow, i should stop
[10:05] <poolie> have a good day all
[10:05] <Riddell> jam: if it's deprecated what replaces it?
[10:05] <jam> have a good evening poolie
[10:05] <jam> Riddell: something about abstract base class Callable, let me see if I can find it
[10:05] <Riddell> docs don't say it's deprecated http://docs.python.org/library/functions.html#callable
[10:05] <vila> jam, poolie, fullermd : I think I'll stick with bare `date` , parsing can be addressed
[10:06] <ccxCZ> type(foo) == types.FunctionType
[10:06] <jam> Riddell: maybe it is deprecated only in py3
[10:06] <ccxCZ> if you want to check for functions only ^
[10:06] <jam> but it certainly exists in 2.7 so feel free to use it
[10:06] <jam> Riddell: http://docs.python.org/dev/whatsnew/3.2.html
[10:06] <jam> says that they restored it
[10:07] <jam> because they felt it was more readable than isinstance(x, collections.Callable)
[10:07] <vila> poolie: cu
[10:07] <jam> so I missed that part. And yes, it is not deprecated after all
[10:07] <Riddell> lovely, thanks
[10:07] <fullermd> vila: Well, if it's meant to be "parsed" by a human, plain output is at least as good as any other.
[10:09] <fullermd> For auto-parsing, epoch would be simplest probably.  Ignoring the mess of nonmonotonicity/continuity of timekeeping in general anyway...
[10:09] <jam> fullermd: I still find -I easier to parse as a human when I'm trying to do something like *compare* the dates
[10:09] <poolie> thisi sa kludge; let's not overoptimize it
[10:09] <poolie> remember you have the option to just ask sysadmins to run experiments for you
[10:10] <jam> Especially if you have to wrap the months (though that shouldn't be a factor here)
[10:10] <jam> poolie: well, I've been pqm-submitting branches that are known-broken which works fine. But for the historical record, it would have been nice to have the datestamps
[10:10] <jam> and then "oh, in rev X things are a lot slower"
[10:23] <vila> jam: python -c 'import datetime; print datetime.datetime.strptime("Wed Aug 31 12:16:18 CEST 2011", "%a %b %d %H:%M:%S %Z %Y")'
[10:24] <jam> vila: still harder to think about, etc. Anyway, it isn't like it really matters, it was just a suggestion.
[10:25] <vila> jam: sure, but poolie preferred trunk only to lower the risks, I'd rather not add risks for portability
[10:25] <jam> I'm pretty sure +%F is portable
[10:25] <jam> it is -Isec that isn't
[10:29] <ccxCZ> %F doesn't seem to be in posix http://pubs.opengroup.org/onlinepubs/000095399/utilities/date.html
[10:30] <fullermd> It's part of strftime in C99 (though not C89)
[10:40] <jelmer> Riddell: hi
[10:40] <jelmer> is it common practice for uploaders to request syncs from Debian, or is it also ok if I just re-upload packages directly to Ubuntu, by myself?
[10:41] <Riddell> jelmer: it's better to request a sync
[10:41] <Riddell> assuming there's no changes to be made
[10:42] <jelmer> Riddell: Cool, thanks.
[10:42] <Riddell> I can do the sync if there's no freezes to care about, just need the bug number
[10:43] <jelmer> Riddell: that'd be great, I forgot you were an archive admin
[10:44] <vila> jelmer: will be afk (lunch), let me know if/when bzr-2.4.0 is deployed on jubany, and thanks for doing it  ;)
[10:44] <jelmer> Riddell: bug 831690
[10:48] <jelmer> Riddell: I'll have a couple of others later today for the other bzr plugin FTBFS bugs, if that's okay.
[10:48] <jelmer> vila: will do :)
[10:48] <Riddell> sure
[12:14] <doude> Hi, all. I try to log with my launchpad login on bzr: bzr lp-login nickname
[12:15] <doude> but I work behind a firewall, and I cannot contact launchpad on SSH port
[12:15] <doude> and now each bzr branch commands fail
[12:16] <doude> How I can unlogin to just clone some launchpad repository ?
[12:16] <vila> doude: you need to remove launchpad_username from bazaar.conf
[12:16] <vila> doude: do you have a bzr recent enough to run 'bzr config' ?
[12:20] <doude> vila: yes
[12:20] <jam> ugh. just accidentally passed a .gz stream to subunit, and it decided the whole thing should be "passthrough", which meant it sent 600kB of garbage to the terminal, which got the system bell *really* excited
[12:21] <jam> if the bell is 3s long, and system-bell is 1/255 of the chars, I estimate it will take 2 hours for it to stop beeping
[12:21] <vila> jam: ouch ;)
[12:21] <doude> vila: thanks a lot for your help
[12:21] <jam> fortunately 'mute' works, but volume itself doesn't
[12:21] <vila> doude: then bzr config --remove launchpad_username in your home dir should do
[12:22] <doude> vila: ok, it works
[12:24] <vila> wow, the garbage killed jam :-/
[12:24] <doude> vila: Is it possible to log to launchpad if the SSH port is blocked ? by another way ?
[12:24] <vila> doude: short answer: no
[12:25] <vila> doude: there are various tricks to route ssh but that will need cooperation from the firewall admin in most cases
[12:27] <vila> jam is back \o/ death to the garbage ! ;)
[12:27] <jam> :)
[12:28] <doude> vila: ok
[12:28] <vila> doude: you can access lp in read-only mode without ssh though
[12:29] <doude> vila: ok
[12:29] <doude> bye bzr men
[12:29] <vila> doude: and if I remember correctly you can even make merge proposals via mail but I don't remember the details
[12:29] <vila> no fast enough :-}
[12:29] <vila> not
[12:32] <jelmer> jam: just to confirm, you were happy with my move-hashcache MP if I added a common base class for WT2 and WT3 ?
[12:33] <jam> jelmer: I think I approved it already, but if not, yes
[12:34] <jam> ah,I think I forgot to actually vote
[12:34] <jelmer> jam: yep, your last vote was needsinfo. anyway, thanks
[12:37] <jam> I just updated it
[12:39] <jelmer> I noticed, already sent it off to pqm :)
[13:16] <Peaker> hey, what's the difference between -c and -r in bzr merge?
[13:16] <Peaker> http://doc.bazaar.canonical.com/latest/en/user-reference/merge-help.html  doesn't make it clear
[13:17] <Peaker> oh, I just read that cherry-picks via "bzr merge" are not tracked by bzr :-(
[13:18] <Peaker> I was wondering whether my current gripe with git (cherry-picks don't track the history, merges force non-modular resolution of all conflicts at the same time) was solved by bzr
[13:25] <jelmer> Peaker: hi
[13:26] <jelmer> Peaker: unfortunately we don't really have either of those features either (yet)
[13:27] <jelmer> we would like to support both, in particular tracking cherry pick merges, but it's a hard problem to solve if you want to get it right.
[13:33] <Peaker> jelmer: well, we're using git, and I noticed some serious problems -- for example:  if you have two branches, A, and B.  You cherry-pick a bad commit A->B.  Now you revert the bad commit only in A. Then you merge A and B -- you will get the bad commit again, because a 3-way merge considers (bad+revert = 0  <  bad)
[13:34] <Peaker> also, a "merge" in a large project that involves many people is pretty horrible -- conflict resolution requires the expertise of many different people!
[13:34] <Peaker> (and they're all forced to share a working tree to work together on the problem)
[13:34] <Peaker> and the conflict resolutions are later very hard to view in isolation, because merge diffs are hard to view (relative to which parent?)
[13:34] <Peaker> So my conclusion is that cherry-picks are really the right way to move work around -- but without their metadata being tracked, it works horribly
[13:35] <Peaker> I think darcs has the right model of "cherry picks" are the only way to move work around and are tracked.. but it has performance issues
[13:43] <jelmer> Peaker: three way merges are relatively easy because there's really only three trees you have to care about
[13:44] <jelmer> Peaker: with cherrypicks you could have to consider all changesets in a repository
[13:45] <jelmer> it would be relatively easy to track cherrypick merges in bzr (in revision properties, for example) but using that information intelligently and without making merge scale badly is the hard bit
[13:49] <Peaker> jelmer: I think darcs just makes merges scale badly :)
[13:50] <Peaker> but I'm thinking it might be worth it... We're getting horrible horrible merges, and cherry-picking everything means we lose all DVCS tracking of everything
[13:50] <Peaker> the only solution we have is to just merge extremely often so no divergence picks up
[13:54] <jelmer> Peaker: btw, I'm pretty sure bzr will pick up the revert in the case you mention
[13:54] <jelmer> Peaker: bzr does track per file history, unlike git, which just tracks content
[13:56] <Peaker> jelmer: but you do a 3-way merge here, no?
[13:57] <Peaker> the per-file history here is that in branch A, the file had changed, and then changed back, so sum of all changes = 0.   In branch B, it just changed. So the sum = change.   3-way merge of 0 and change = change, no?
[13:57] <jelmer> Peaker: bzr doesn't look at the checksum to see if a file has changed. It keeps track of what revision it was last changed.
[13:58] <Peaker> so what would bzr do here? it would see the file changed in branch A, and then changed back, and consider it a conflict?
[14:00] <jelmer> Peaker: it should have enough info to create a conflict; I'm not sure if it actually creates one
[14:00] <Peaker> jelmer: git has the same info, of course, it is also a question of whether it looks at that info
[14:01] <jelmer> Peaker: git doesn't know what revision a file last changed in, unless it's going to scan history (which it doesn't)
[14:01] <jelmer> it just finds the common base to use for the 3 way merge
[14:01] <jelmer> abentley: hi
[14:01] <Peaker> jelmer: ah, yes, perhaps
[14:01] <abentley> jelmer: hi.
[14:01] <Peaker> jelmer: though I think merge does scan history in various cases
[14:02] <jelmer> Peaker: it scans it to find the base for the three way merge
[14:03] <Peaker> jelmer: Well, that scan is per-file, so it had already encountered all of the version that changed it
[14:03] <jelmer> Peaker: finding the base for the merge? that can only be done based on the revision graph
[14:04] <Peaker> jelmer: yeah -- and when walking that graph, it sees whether that file changed in each of the revisions
[14:04] <jelmer> Peaker: it doesn't look at the files during that scan, just the revisions
[14:05] <Peaker> jelmer: I'm pretty sure it does the 3-way merge basis lookup on a per-file basis, according to the debug prints visible when encountering conflicts. But I'm not entirely sure
[14:05] <Peaker> and if it does that -- it should not be expensive to see whether the file changed or not, in those revs, if it didn't already
[14:06] <jelmer> Peaker: it is fairly expensive because to know what file has changed you have to apply the rename/copy detection heuristics
[14:07] <jelmer> Peaker: to follow the changed files I mean
[14:07] <jelmer> as far as I understand it it uses the revision graph to find the base revision, and then applies the heuristics between just the base revision and the other/this trees
[14:10] <jelmer> Peaker: bzr's merge doesn't generate a conflict either
[15:05] <vila> jelmer: care to have a look at https://code.launchpad.net/~vila/udd/806425-append-revs-only/+merge/73531 ?
[15:09] <jelmer> vila: sure
[15:09] <jblue> Q: is there a way to commit/operate on a specific set of changes after a 'bzr status'?  For example, if bzr status shows removed, modified, and unknown files, and I want to work only with the removed files, is there some way to specify that?
[15:11] <vila> jblue: 'bzr commit file1 file2' should just work
[15:12] <jblue> it does, but was looking for a method working with that set, in an instance where I have a lot of files being removed.
[15:12] <jblue> but also have a lot of files modified, and their locations are intermixed
[15:12] <jblue> so specifying them one by one is a bit tedious
[15:13] <vila> may be 'bzr qcommit' provides some help ?
[15:14] <vila> Did you get there after a merge or some heavy refactoring from an IDE ?
[15:14] <jblue> heavy refactoring.. basically several files have been removed, modified, and added, and I'd like to do the removal first, then work with the others
[15:15] <vila> but no file has been both removed and added right ?
[15:16] <jblue> well it was, but I quickly saw that was going to be a headache, so I've reverted, and am doing the removal first
[15:17] <vila> I meant, you didn't *rename* files by doing remove/add right ?
[15:17] <jblue> no
[15:17] <vila> ok, good
[15:26] <jelmer> vila: r=me
[15:26] <vila> jelmer: thanks, I'm deploying
[15:26] <vila> ha, damn, been interrupted and forgot to answer
[15:27] <vila> jelmer: my understanding is that a_r_o should only be applied in *some* cases so having a global switch doesn't make sense at this point
[15:28] <jelmer> vila: I mean, having a global variable that's set to True or False
[15:28] <vila> what for ? switch it back to True ?
[15:29] <jelmer> yeah
[15:30] <vila> AIUI, using it for local branches is just a Bad Idea, so after some checking I will probably just get rid of the calls themselves
[15:31] <vila> for the lp branches, AIUI again, the rules are not well understood yet so we probably end up replacing the calls by some more logic
[15:31] <vila> so in the end, none of the actual calls should survive
[15:31] <vila> jelmer: or do you expect such a breakage that we want to come back to a_r_o=True ?
[15:32] <jelmer> vila: I'm not really bothered either way :)
[15:32] <vila> hmm, looks like lp has or had some transient issues...
[15:32] <gypsymauro> I've some mess in my repo and if I try to do a ci it says: bzr: ERROR: Bound branch BzrBranch7('file:///....') is out of date with master branch BzrBranch7, To commit to master branch, run update and then commit. but I want to be sure that nothing in my working directory will be changed.. I'm sure my current version is the correct version
[15:32] <gypsymauro> any hint?
[15:35] <vila> gypsymauro: hi
[15:35] <jelmer> gypsymauro: I think "bzr diff -rbranch:/path/to/master/branch" should tell you what it would change
[15:35] <vila> what does 'bzr missing' says ?
[15:37] <gypsymauro> is says that I've two extra revision (and is true, i done some ci --local)
[15:38] <vila> any uncommitted changes ?
[15:38] <gypsymauro> the bzr diffs displays me 29645 lines..
[15:39] <jelmer> gypsymauro: in that case it shouldn't change your working tree, although it will change your local commits to be pending merges
[15:40] <gypsymauro> vila: what do u mean? I committed locally, only this , how can I now commit to the remote repository?
[15:41] <jelmer> gypsymauro: if you run "bzr up" and then "bzr commit" that will commit your changes to the local repository
[15:41] <jelmer> argh
[15:41] <jelmer> s/local/remote/
[15:48] <gypsymauro> jelmer: and this for sure doesn't change anything in my local repository? (the update term scares me :)
[15:49] <jelmer> gypsymauro: it will update bzr metadata in the local tree - it will change your two local commits to be pending merges, and your branch tip to match that of the remote branch
[15:50] <jelmer> gypsymauro: if the remote branch doesn't have any extra revisions (as "bzr missing" seems to indicate) then it shouldn't change any of the files in your tree
[15:52] <gypsymauro> jelmer: doh..
[15:52] <gypsymauro>  bzr conflicts
[15:52] <gypsymauro> Conflict: can't delete  foo/bar  because it is not empty.  Not deleting. Conflict because  foo/bar is not versioned, but has versioned children.  Versioned directory.
[15:53] <gypsymauro> damn.. it creates a lot of .BASE .OTHER and .THIS file...
[15:58] <gypsymauro> it's a nightmare..
[15:59] <jelmer> gypsymauro: ouch, that sucks :(
[15:59] <fullermd> I keep wishing we'll just squirrel ci --local away somewhere deep hidden...
[15:59] <jelmer> gypsymauro: you had local commits that added foo/bar ?
[16:00] <jelmer> fullermd: yeah, me too. I think we should just get rid of them.
[16:00] <gypsymauro> damn...
[16:01] <gypsymauro> if I recover from a backup my foo/bar? this resolves my conflicts?
[16:01] <gypsymauro> or I've to merge manually ?
[16:02] <jelmer> gypsymauro: I suspect "bzr resolve --take-other" might fix this for you, but I'm not entirely sure
[16:02] <vila> gypsymauro: sry was called elsewhere
[16:03] <vila> gypsymauro: if you have conflicts, a merge already occured (triggered by update)
[16:03] <gypsymauro> jelmer: uhm i suppose the .THIS version is the correct
[16:03] <vila> gypsymauro: how conflicts ?
[16:03] <vila> gypsymauro: how many conflicts ?
[16:03] <gypsymauro> vila: 47
[16:04] <gypsymauro> wc -l
[16:04] <vila> hmm
[16:04] <vila> !paste
[16:04] <vila> gypsymauro: can you pastebin the output of 'bzr conflicts' ?
[16:04] <vila> gypsymauro: and 'bzr st'
[16:05] <gypsymauro> http://pastebin.com/TCYWVLy6
[16:06] <gypsymauro> and http://pastebin.com/nWPRg99U
[16:08] <jelmer> Riddell: still there?
[16:08] <jelmer> Riddell: another sync is bug 837956
[16:09] <vila> gypsymauro: :-/ Looks like you added files that were also added remotely...
[16:09] <vila> gypsymauro: but you said 'bzr missing' only reported local revisions right ?
[16:10] <jelmer> vila: the problem is that update works in two phases; first it updates to the remote branch, then it merges in the local commits again
[16:10] <jelmer> vila: I *think*
[16:10] <vila> jelmer: but we stop as soon as we get a conflict (or was it discussed but not implemented ?)
[16:10] <vila> gypsymauro: what bzr version are you using ?
[16:10] <jelmer> vila: sure, but he was up to date
[16:10] <fullermd> The usual cause of kerfufflage there is when you have uncommitted changes as _well_ as local commits.
[16:11] <vila> fullermd: I asked for uncommitted changes first ;)
[16:11] <fullermd> I thought we added some guard on that, but maybe we didn't.  I dunno, I stay too far away from those dragons to remember   :p
[16:11] <gypsymauro> Bazaar (bzr) 2.1.2
[16:11] <vila> gypsymauro: ouch, OS/version ?
[16:12] <gypsymauro> debian squeeze
[16:13] <jelmer> Riddell: and I have a bzr upload waiting for approval
[16:13] <Riddell> jelmer: waiting where?
[16:13] <vila> gypsymauro: rrright, let's do it the old fashion way then
[16:14] <vila> gypsymauro: do you have the qbzr plugin installed ?
[16:15] <jelmer> Riddell: waiting for approval by an archive admin; looks like it was just rejected
[16:15] <ScottK> jelmer: I rejected 2ubuntu1.  You just uploaded 3ubuntu1.
[16:16] <ScottK> At this point it needs to wait until after Oneiric Beta 1 is done.
[16:16] <jelmer> ScottK: ah, my mistake. Thanks!
[16:16] <ScottK> (I also pinged you on #ubuntu-devel about it ...
[16:16] <ScottK> )
[16:17] <gypsymauro> vila: now yes :D
[16:17] <vila> gypsymauro: great, try 'bzr qlog'
[16:18] <jelmer> ScottK: yep, not sure why I missed that
[16:18] <gypsymauro> vila:  ok
[16:18] <vila> gypsymauro: we need to find the last revision committed locally (we'll need the revision on your remote branch to, but this one will be easy to get)
[16:18] <gypsymauro> i've two light blue circles
[16:19] <vila> gypsymauro: 'bzr revno' ?
[16:19] <gypsymauro>  ok the last is 14
[16:19] <vila> do you see a 'pending merges' label ?
[16:19] <gypsymauro> yes
[16:19] <gypsymauro> 14.1.2
[16:20] <gypsymauro> and another blue 14.1
[16:20] <gypsymauro> 14.1.1
[16:20] <vila> exellent, that's your local commits
[16:20] <gypsymauro> without the pending msg
[16:20] <gypsymauro> exactly
[16:20] <vila> justasec
[16:22] <vila> gypsymauro: roughly, we will create a branch from remote and 'merge ../with-conflicts -r14.1.2'
[16:25] <gypsymauro> vila: I'm in ur hands... take care about 2 weeks of work :) I've a backup btw
[16:26] <vila> gypsymauro: i.e.: in a new directory: bzr branch <remote> recover ; cd recover ; bzr merge <conflicts> -r14.1.2
[16:29] <gypsymauro> vila: doing the first step
[16:29] <vila> gypsymauro: no worries, try (above the dir with conflicts) : bzr branch <conflicts> -r14.1.2 my-precious
[16:29] <gypsymauro> what do u mean with <conflicts>
[16:30] <vila> your checkout dir
[16:30] <gypsymauro> you mean where I've my precious sources?
[16:30] <vila> I call it <conflicts> to denote that's the one where the conflicts are *now*
[16:30] <vila> hehe, yeah, except you've committed them, so they are safe in a revision in the repo
[16:31] <gypsymauro> my local repo
[16:34] <vila> yes
[16:35] <fullermd> Wait, he's committed the conflicted merge?
[16:35] <vila> no
[16:35] <fullermd> So how would the local commits (now pending merges) have a dotted revno available?
[16:35] <vila> can't commit with conflicts
[16:36] <fullermd> Wouldn't you need to go by revid?
[16:36] <vila> hlol, good point, we need the revids
[16:37] <vila> gypsymauro: sry, in that qlog window, note the revid for 14.1.2 checking that's indeed your last local commit
[16:37]  * fullermd is a cheenius sometimes.
[16:38] <vila> fullermd: thanks for the heads-up
[16:38] <fullermd> vila: You'll get my bill in the mail   ;p
[16:38] <vila> hehe, as usual, don't forget to bill for some more goats too, say half a dozen ?
[16:45] <gypsymauro> vila: ok now I try , and all that .THIS and .OTHER will disappears?
[16:45] <vila> gypsymauro: so you've got a copy of your remote branch ?
[16:45] <gypsymauro> yes
[16:46] <gypsymauro> I don e  bzr branch <remote> recover ; cd recover ;
[16:46] <gypsymauro> steps
[16:46] <gypsymauro> now I'm doing that bzr merge <conflicts> -r14.1.2
[16:46] <vila> go there and do 'bzr merge ../<conflicts -r<revid>'
[16:46] <vila> gypsymauro: as fullermd pointed out the revno is probably not available (qlog lied ;)
[16:46] <vila> so you need,
[16:46] <vila> gypsymauro: sry, in that qlog window, note the revid for 14.1.2 checking that's indeed your last local commit
[16:48] <gypsymauro> bzr: ERROR: Requested revision: u'14.1.2' does not exist in branch:
[16:48] <gypsymauro> doh...
[16:48] <vila> right, fullermd was :)
[16:49]  * fullermd buffs his nails and looks important.
[16:49] <vila> gypsymauro: qlog *pretends* the revnos exist, but they don't until you commit
[16:49] <gypsymauro> I'm getting lost
[16:50] <vila> gypsymauro: just go back to qlog, select 14.1.2 and it should display a pane with some details on the revision
[16:50] <gypsymauro> which detail do u need?
[16:51] <vila> gypsymauro: one of them is the revid which is used internally and in some recovery contexts, normally you only deal with revnos (14.1.2 is a so-called dotted revno)
[16:52] <vila> gypsymauro: a revid is ugly, except it probably has your id/email in it so it's not that ugly ;)
[16:52] <gypsymauro> vila: it's something like email@....bla bla bla?
[16:52] <gypsymauro> ah ok
[16:52] <gypsymauro> so -rrevid?
[16:52] <vila> yup, pedantically -rrevid:email@bla bla bla
[16:52] <gypsymauro> All changes applied successfully.
[16:53] <vila> bzr st ?
[16:53] <vila> you should get something that looks like a summary of your two local commits
[16:53] <vila> ditto for 'bzr diff'
[16:55] <gypsymauro> vila: well where is applyed the merge?
[16:55] <vila> gypsymauro: what does 'bzr st' says ? It should finish with 'pending revisions' blah
[16:56] <vila> s/finish/ends/
[16:56] <gypsymauro> I mean in the recover folder I've the old version of files
[16:56] <vila> you did the merge there right ?
[16:56] <gypsymauro> pending merge tips: (use -v to see all merge revisions)
[16:57] <gypsymauro> yes of course
[16:57] <vila> so you just merged the last 'commit --local' you did in <conflicts>
[16:57] <vila> gypsymauro: there was no uncommitted changes when did update in <conflicts> right ?
[16:58] <gypsymauro> no wait I didnt' made the last commit --local I tried to commit directly on the remote
[16:59] <vila> argh
[16:59] <vila> ><
[16:59] <gypsymauro> I forgot the --local command..
[16:59] <gypsymauro> if I move all the .THIS file to the original file?
[16:59] <vila> the fatal trap :-(
[17:00] <sidnei> what's that really shiny github-like site for bzr hosting which i can never remember the name?
[17:00] <vila> well, now it depends which merge failed, it's unclear from there, so, chose a file you know well and check whether the right one is .OTHER or .THIS
[17:00] <vila> gypsymauro: well, now it depends which merge failed, it's unclear from there, so, chose a file you know well and check whether the right one is .OTHER or .THIS
[17:01] <gypsymauro> vila: is the .THIS
[17:01] <jelmer> sidnei: http://wiki.bazaar.canonical.com/Hosting
[17:01] <jelmer> sidnei: I'm not sure which one of those you mean
[17:02] <vila> gypsymauro: two choices from here
[17:02] <vila> gypsymauro: either you go back to <conflicts> and resolve the conflicts there OR
[17:02] <sidnei> jelmer, might be mergebox, but it does not look like what i remember
[17:02] <sidnei> the name i remember was codemaster or something
[17:03] <vila> gypsymauro: you go to recover and do: 'bzr revert --no-backup; bzr pull --overwrite -rrevid:<revid of 14.1.2>'
[17:03] <gypsymauro> vila: what does that?
[17:04] <gypsymauro> vila: uhm i think is better to resolve conflicts
[17:04] <vila> gypsymauro: the first one is going forward resolving the conflicts
[17:04] <gypsymauro> yeah yeah I mean the second
[17:04] <gypsymauro> but if is it what I suppose I prefer the second :)
[17:04] <gypsymauro> the first sorry
[17:05] <vila> gypsymauro: the second one is stepping back, restore your working tree as it was when you miss --local
[17:05] <vila> gypsymauro: it all depends on what the conflicts are which is hard for me to judge
[17:05] <gypsymauro> vila: just can you help me telling what to do when there is a . THIS .OTHER conflict?
[17:05] <jelmer> sidnei: mergebox isn't really shiny
[17:06] <gypsymauro> vila: I've to move the .THIS over the original file and then run bzr resolve myfile?
[17:06] <vila> gypsymauro: is there a conflict-type topic in 'bzr help topics' ?
[17:06] <vila> gypsymauro: that's the general idea, yes
[17:06] <jelmer> sidnei: it took me a while to hear about bzr.bz too, it's been there for a long time without anybody knowing
[17:07] <vila> gypsymauro: one by one (especially with bzr-2.1 where I don't remember which bugs were still there)
[17:07] <vila> gypsymauro: for the record, we have a new series every 6 months and 2.4.0 has just been released so 2.1 is 18 months old
[17:07] <gypsymauro> vila:  ok, mv or cp? and then the generated files wil disappear? (.this .other..)
[17:08] <vila> gypsymauro: both should work
[17:09] <gypsymauro> doh... bzr: ERROR: Could not acquire lock
[17:09] <gypsymauro> /.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable
[17:09] <vila> gypsymauro: 'bzr break-lock'
[17:09] <vila> no wait !
[17:09] <vila> quit qlog first
[17:09] <gypsymauro> who is locking that? I've nautilus plugin
[17:09] <vila> try again
[17:09] <vila> in 2.1, could be qlog, can't remember the details
[17:10] <sidnei> jelmer, it totally escapes me now, but i rememember poolie mentioning it in an email, which i can't find. hopefully im not dreaming. it definitely doesn't look like mergebox, unless they rebranded.
[17:10] <sidnei> for worse that is ;)
[17:10] <jelmer> sidnei: :)
[17:12] <gypsymauro> vila: tanx for all ur help :) last question
[17:12] <gypsymauro> how to solve the Conflict: can't delete foo/bar because it is not empty.  Not deleting =
[17:12] <gypsymauro> ?
[17:12] <vila> right, so, what is inside foo.bar ?
[17:13] <gypsymauro> other folders
[17:13] <vila> gypsymauro: which are also involved in conflicts ?
[17:21] <jam> sidnei: sloecode?
[17:21] <jam> https://launchpad.net/sloecode
[17:21] <jam> not really a website, though
[17:23] <sidnei> jam, nope. the site i remember had a black background and some shiny polished metal like images, very apple-y. oh well :/
[17:26] <jam> sidnei: I remember a pastebin sort of website
[17:26] <jam> sidnei: http://chopapp.com/#
[17:27] <jam> but it isn't bzr
[17:30] <jam> elliot just mentioned http://bzr.bz
[17:31] <vila> gypsymauro: so you're back on track ?
[17:31] <gypsymauro> I hope
[17:31] <gypsymauro> tank you vila
[17:31] <vila> gypsymauro: no you know why fullermd....
[17:32] <gypsymauro> I'm sorry but my bzr skills ar so low :( I need to study it again!
[17:32] <vila> fullermd: I just can't believe you went out/in just around the time we needed to fix gypsymauro issues
[17:32] <gypsymauro> fullermd: :D
[17:32] <vila> fullermd: you're just faking those connections msgs right ?
[17:32] <gypsymauro> you are great guys
[17:32] <gypsymauro> tanx tanx tanx again
[17:32] <gypsymauro> really
[17:32] <gypsymauro> yuhu!
[17:32] <vila> gypsymauro: well, as fullermd was hinting, --local is.... unusual
[17:32] <fullermd> My spidey sense made me do it.
[17:33] <vila> gypsymauro: enjoy !
[17:33] <vila> and on that positive note, I will join family for dinner ;)
[17:34] <fullermd> Need to me break something else so you can get out of that?   ;)
[17:34] <vila> fullermd: so, just read the logs, you went out when he realized he... forgot --local...
[17:35] <TA1CZ> hello
[17:35] <TA1CZ> may I ask something about Bazaar explorer for windows.
[17:36] <TA1CZ> Run command: bzr branch lp:~openerp/openobject-addons/trunk C:/launchpad/openobject-addons/trunk --use-existing-dir
[17:36] <TA1CZ> Connected (version 2.0, client Twisted)
[17:36] <TA1CZ> bzr: ERROR: [Error 5] Access is denied: 'c:\\users\\user\\appdata\\local\\temp\\tmpiawygw.pag'
[17:36] <TA1CZ> I get this error...
[17:37] <jelmer> TA1CZ: pag rather than pack?
[17:37] <jam> TA1CZ, jelmer: I believe that is a failure of pageant
[17:37] <TA1CZ> is there any suggestion?
[17:37] <jam> try re-setting up putty
[17:37] <jam> or making sure your key is set up, etc.
[17:38] <jam> or just stop pageant entirely
[17:38] <TA1CZ> I used puttygen for generating the keys..
[17:38] <TA1CZ> both private and public..
[17:38] <jam> TA1CZ: the issue with $TEMP is usually while communicating to the local pageant server
[17:38] <jam> it doesn't really matter what the keys are
[17:39] <TA1CZ> the putty agent is also working on the right side of windows
[17:40] <TA1CZ> I added private.ppk key
[17:40] <jam> TA1CZ: try stopping the local putty agent for a bit
[17:40] <TA1CZ> o.k.
[17:41] <TA1CZ> Run command: bzr branch lp:~openerp/openobject-addons/trunk C:/launchpad/openobject-addons/trunk --use-existing-dir
[17:41] <TA1CZ> Connected (version 2.0, client Twisted)
[17:41] <TA1CZ> bzr: ERROR: Connection error: Unable to authenticate to SSH host as
[17:41] <TA1CZ>   karen-denki@bazaar.launchpad.net
[17:41] <TA1CZ> supported auth types: ['publickey']
[17:41] <TA1CZ> Run command: bzr branch lp:~openerp/openobject-addons/trunk C:/launchpad/openobject-addons/trunk --use-existing-dir
[17:41] <TA1CZ> Connected (version 2.0, client Twisted)
[17:41] <TA1CZ> bzr: ERROR: Connection error: Unable to authenticate to SSH host as
[17:41] <TA1CZ>   myID@bazaar.launchpad.net
[17:41] <TA1CZ> supported auth types: ['publickey']
[17:41] <jam> TA1CZ: is the user-id correct?
[17:41] <TA1CZ> the result is like this when I stop the agent!
[17:41] <jam> (just to start from the beginning)
[17:42] <TA1CZ> o.k.
[17:42] <jam> We can't auth via public-key because you don't have the key agent around, and putty uses a different key
[17:42] <jam> format by default
[17:42] <jam> .ppk vs id_rsa.pub
[17:42] <jam> however, start putty again
[17:42] <jam> and I think you might see a $TEMP failure
[17:42] <jam> unfortunately, I've seen this on one machine (our ec2 build host) only, and haven't been able to reproduce it
[17:42] <TA1CZ> which putty?
[17:43] <jam> on my home machine, etc.
[17:43] <jam> "pageant"
[17:43] <jam> I should have been clearer
[17:44] <TA1CZ> :(
[17:45] <jam> TA1CZ: it is failing with TEMP again?
[17:45] <jam> TA1CZ: what os version/
[17:45] <jam> ?
[17:45] <TA1CZ> windows 7
[17:46] <TA1CZ> so could you say step by step what should I must do is you dont mind?
[17:46] <TA1CZ> because I totally confused..:(
[17:48] <TA1CZ> is this relevant with authentication.conf?
[17:49] <jam> TA1CZ: not really. I think I can work out a workaround for you
[17:49] <jam> you need to run puttygen again
[17:49] <TA1CZ> o.k. now I am running puttygen
[17:49] <jam> (note, I'm discussing it from memory, and I'm not logged into Windows right now, but I'll do my best)
[17:49] <jam> you should be able to load the private.ppk that you created
[17:50] <vila> jam: nice mail about fdatasync, make check timing patch landed, first log rsync'ed, the stamps are lost in the noise but nothing a crude parser can't decipher, dinner time here but you'll got a parser first thing I touch this keyboard again ;) Unless you beat me to it that is :-p
[17:50]  * vila really goes to dinner now ;)
[17:51] <jam> vila: for now, I'm focusing more on test cases individually. If I have 'pqm-stdout.gz' it has the subunit timestamp stream
[17:51] <jam> so 'date' doesn't really matter.
[17:51] <TA1CZ> o.k. when the putty gen is on the stage.. I load the private.ppk key by pressing Load button.. it is loaded.
[17:51] <vila> jam: great
[17:51] <jam> TA1CZ: Now you want to export the key into the "openssh" format
[17:51] <jam> which you've already done a bit of, since you uploaded the openssh public key form to launchpad
[17:53] <vila> jam: spurious spikes for tests have been encountered when dealing with socket leaks, cycle checks from mgz and so on, you may want to give a spin merging it into one of your born-to-not-land branches
[17:54] <jam> vila: could be interesting. But I believe Martin also indicated the machine is shared
[17:54] <jam> so if they're doing stuff at the same time, its gonna get whacky
[17:54] <jam> the test suite was 2.5hrs for a couple of runs, then 3.5 for the other times of the day
[17:54] <vila> jam: sure, primary cause, but 3x...
[17:54] <jam> vila: just the source of variability
[17:55] <jam> primary cause is still probably fdatasync, which is another failed log I'm looking at
[17:55] <jam> but there seems to be slightly more than that as a real cause, and then hard-to-measure-because-of-system variability
[17:55] <jam> 2.3 can finish as fast as 45min, but took 1:45 last night
[17:55] <jam> etc.
[23:17] <AuroraBorealis> does bzr hash files when it does a commit?
[23:26] <Peng> AuroraBorealis: Hash in what way?
[23:26] <AuroraBorealis> just wondering if this statement is true for bazaar as well
[23:26] <AuroraBorealis> context: kernel.org was compromised recently
[23:27] <Peng> It was?
[23:27] <AuroraBorealis> http://pastebin.com/8CKqBPQC
[23:27] <AuroraBorealis> yeah it was
[23:28] <AuroraBorealis> (see https://www.kernel.org/, first news item)
[23:28] <Peng> Yeah.
[23:28] <AuroraBorealis> so basically, can someone change something without bazaar knowing about it?
[23:28] <Peng> Bazaar doesn't uses hashes as revision IDs, but it does hash everything.
[23:28] <AuroraBorealis> so if someone did do that you would be able to detect it if you rechecked the repo or something
[23:29] <Peng> I'm not quite awake enough to think about this problem.
[23:30] <AuroraBorealis> xD
[23:30] <AuroraBorealis> i dont know enough about the actual structure of the repo itself to figure it out
[23:30] <Peng> It would most definitely be possile to verify it somehow, but I don't know how easily.
[23:32] <AuroraBorealis> isn't there a --recheck option
[23:33] <Peng> Yes.
[23:34] <mathrick> hiya
[23:34] <AuroraBorealis> would be an interesting test to see if someone could modify the repo and see if said recheck catches it.
[23:34] <mathrick> http://doc.bazaar.canonical.com/latest/en/mini-tutorial/index.html#creating-your-own-copy-of-another-branch <-- why does it even talk about init-repo?
[23:34] <AuroraBorealis> as modifiying the repo malitiously would be bad.
[23:34] <mathrick> without explaining what it is and why it is there?
[23:34] <mathrick> that's really outside of the scope of a mini tutorial, IMHO, and should be removed
[23:35] <AuroraBorealis> file a bug about it
[23:36] <AuroraBorealis> it is probably overkill for said mini tutorial.
[23:37] <Peng> AuroraBorealis: "bzr check" would certainly find ordinary corruption, but a clever hacker would modify all the hashes, no? That would probably blow up pretty quickly as people with uncompromised copies of the repo interacted with it, but it's not something I have any knowledge about.
[23:38] <AuroraBorealis> well what that git comment said was that all the future commits require that all the previous commits are correct
[23:38] <AuroraBorealis> although i don't really know how that works, but another example is with bitcoin blocks, each block has the hash to the previous block, creating a 'chain', so you can't modify a block or else the hashes won't match up
[23:41] <Peng> But it can't actually verify that the hashes of all previous revisions are *correct* in every operation.
[23:41] <Peng> Can it?
[23:41] <AuroraBorealis> well true.
[23:42] <AuroraBorealis> if the person manages to maliciously modify commit 100 for example
[23:42] <AuroraBorealis> and manages to change the hashes for 1-99 then i guess it would be undetectable
[23:42] <AuroraBorealis> but i'm sure something else would break...
[23:43] <AuroraBorealis> like a merge would show it as a conflict
[23:44] <AuroraBorealis> and thats how bitcoin does it as well, is that its a p2p network, so you would have to get everyone to have the malicious block or else you would realize that its wrong
[23:44] <Peng> Might be an uncommonly-modified file.
[23:44] <Peng> Like I said, I'm too tired to think about this.
[23:44] <AuroraBorealis> xD
[23:44] <AuroraBorealis> well wake up
[23:44] <Peng> Worst case, even without any hashing, you can obviously do a diff between a questionable copy and a known-good copy.
[23:45] <AuroraBorealis> yeah, even if its uncommonly modified, if anyone had branched the good copy and tried to merge it back in, it would show up as a conflict