On 13 Apr 2009, at 21:40, Reinier Lamers wrote:
My gut feeling is that a patch type for changing indentation (initial
whitespace) would be quite doable. Then you can tell darcs that
those patches
don't conflict with hunk patches that leave the whitespace intact.
That could be useful on its own. What about a patch type that
affected end-of-line whitespace, does your gut tell you those would be
doable, or are their complications there too?
So I was wondering, would it be possible for darcs to have a patch
type that could change whitespace only, allowing the merge of, say,
patches trying to change:
"blah blah blah"
to:
"blah blah blah"
and:
"blah BLAH blah"
the result being:
"blah BLAH blah"
But that's harder, because we can see that the second white space
sequence in
the third line is 'the same' as the second white space sequence in
the first.
But how can we define this sameness in a computer program?
I was thinking that any non-whitespace character *at all* would have
to be preserved, so:
/([\s]*)(([^\s]+)($|[\s]+))+/
would match both if you expanded and had the same values for
parenthesis 3. If that flagrant abuse of regexes makes sense :-/
It's past my bedtime to be thinking hard though...
One could simply use a numeric index (like 'the second sequence'
here). Such
whitespace patches only commutes with hunk patches that do not
insert or
remove any whitespace sequences. Any patch that inserts whitespace
sequences
or removes them would be a hunk patch. Can anyone see a problem with
this
approach?
Pretty sure we're thinking the same thing. But it would have to merge
on a per-line basis to be any use in practice.
A problem might be that a whitespace patch that goes from " zip a b"
to "zip a
b" would commute with a hunk patch that goes from " zip a b" to "
unsafePerformIO $ exitFailure", while intuitively I think the
commute should
fail because the hunk patch changes the line to be a semantically
completely
different line, even if it leaves the number of whitespace sequences
intact.
Hmmm, I can see it might happen, but is it likely? Changing initial
line indent usually indicates a change of logic anyway (if you keep
your code sanely formatted), so there's a chance there'd be other
conflicts.
def my_method
if x
puts "moo"
else
puts "quack"
end
end
+
def my_method
if x
puts "moo"
else
puts "woof"
end
end
=>
def my_method
if x
puts "moo"
end
puts "woof"
end
?
How would these merge? Would it be desirable? (Maybe should not, as
they indicate a lack of communication in a team, but it would not
actually be a problem in the presence of a thorough automated test
suite.)
WDYT?
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
http://aviewfromafar.net/
http://twitter.com/ashleymoran
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
