On Tue, 2005-04-19 at 16:00 -0700, Tupshin Harper wrote: > Ray Lee wrote: > > >Here's where we disagree. If you checkpoint your tree before the > >replace, and immediately after, the only differences in the > >source-controlled files would be due to the replace. > > > This is assuming that you only have one replace and no other operations > recorded in the patch. If you have multiple replaces or a replace and a > traditional diff recorded in the same patch, then this is not true.
I had a precondition on my argument (not quoted), that the code was checkpointed before and after. Obviously, a large set of changes in one patch is a problem. However, a darcs replace is (effectively) a commit on its own, so I was limiting myself to the same situation under a different system. > A more fundamental problem comes back to intent. If I have a file > "foo" before: > a1 > a2 > and after: > b1 > b2 > is that a "replace [_a-zA-Z0-9] a b foo" patch, or is that a > -a1 > -a2 > +b1 > +b2 > patch? Okay, so in reading the online darcs manual (yet) again, I now see that it allows regular expressions for the match and replace, which means multiple unique tokens could change atomically. (Does anyone actually *use* regexes? Sounds like a cannon that'd be hard to aim.) Regardless, I only care about code, not free text. If it's in a language that doesn't do some use-'em-as-you-need-'em duck typing spiel (<cough>python</cough), then the context of your patch (namely, the file) already has those tokens somewhere in them. And I bet that if *you* looked at that file, you could tell if it was a replace or a mere textual diff. Am I wrong? > Note that this comes down to heuristics, and no matter what you > use, you will be wrong sometimes, *and* the choice that is made can > substantively affect the contents of the repository after additional > patches are applied. Unless I'm missing something, the darcs replace patch can already do the wrong thing. If I do a replace patch on a variable introduced in a local tree, then do a darcs replace on it before committing it to a shared repository, and coder B introduces a variable of the same original name in my copy, then there's a chance that the replace patch will incorrectly apply upon his newly introduced variable. No? > It's provable that you can not. I'm still not seeing the problem, at least when it comes to ANSI C. Ray - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html