I don't mean to blow this up into a bigger deal than it is, but I would like to
be clear about why we want to do this, and whether it fits consistently with
our other behaviours.
Yes, I think we should silently integrate an existing file that is identical
(subject to keywords, EOL style, etc.) to the one added by "update", but why?
The reason is that this (merging of identical changes) is the behaviour we
already support in other cases, isn't it? This is effectively (where "||"
means "merging parallel changes"):
- (WC) whole-file unscheduled add || (repos) whole-file add
Do we behave identically for:
- (WC) whole-file scheduled add || (repos) whole-file add
including conflict handling where the changes aren't identical? I hope so.
What about:
- (WC) whole-file unscheduled delete || (repos) whole-file delete
- (WC) whole-file scheduled delete || (repos) whole-file delete
(without going into details about whether it's the same text version being
deleted, and what we do if it's not), and
- diff hunk add || diff hunk add
- diff hunk delete || diff hunk delete
?
Peter N. Lundblad wrote:
>
> - Instal the textbase and properties as usual.
> - If the working file exists, detranslate it according to the new
> properties and compare to the new textbase.
> - If they are the same, fine, else flag the file as conflicted.
Yes, except that what we do when they conflict is important.
If the unversioned file is similar to the versioned one, then it is fine to
treat it like we normally treat update conflicts, putting conflict markers in
the text (or just saving a copy if it is "binary").
Does our three-way merge handle this situation well: merging the adds of two
similar files from an absent (~ empty) ancestor, and marking only the places
where the additions conflict? (Or does it just put the two whole-file lumps of
text with a separator between them?)
If we can't easily do a good merge, would we accept just indicating that it
conflicts, leaving it unchanged, and saving the ".rY" version (probably not the
(non-existent) ".X" and perhaps not the (same as WC) ".mine")?
If the unversioned file is completely different from the versioned one, then
the user probably wants to retain a copy of it. It would be awful if we filled
it with conflict markers and didn't provide a way to revert it to its previous
state. Of course we do provide a way: the ".mine" file. OK. So the user has
the ability to return to the pre-update state in all cases of conflict. Yes?
Good.
(I have thought before that it would be really good to have the ability to
return a failed "update" as a whole, not just individual files, to its previous
state. Update would be closer to atomic. If the update fails in any way -
conflicts, aborts, or whatever - then the user could return the WC to the
previous state which was at least compilable and self-consistent, and then sort
out the problem. I mention that just because it's )
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 21 14:12:09 2005