[darcs-devel] darcs patch: remove commute_nameconflict (rarely invoked and ugly)

David Roundy droundy at darcs.net
Wed Aug 8 17:06:11 UTC 2007


On Wed, Aug 08, 2007 at 07:10:18AM +0200, Eric Y. Kow wrote:
> > We used to have a special treatment for conflicts in which one
> > patch creates a file while another patch renames a file to have
> > the same name.  It's a rare case, and I think we probably want
> > to just fix it right now as a cleanup.
> 
> I'm not sure I would count on the rarity of events.  For that matter, I
> have seen cases of this in the wild.  What happens without the code?
> Does it blow up, or just do something less useful?

Without this code, past resolved conflicts should pose no problem (unless
folks try to re-do the merge).  Basically, this is like the old "merger
0.9" patches:  we disabled the creation of those patch types ages ago, and
the result was that any merge that had created such a patch would need to
be kept in place (not merged again), or you'd run into trouble.

> > An option to alleviate the danger would be to write a function in
> > darcs check that checks if any such "nameconflict" patches exist.
> 
> Presumably, that would not help with the case where you pull such a
> patch in, and say, it conflicts with your unsaved changes?

No, it would be in the spirit of "darcs optimize --modernize-patches",
except that there's nothing to change.  It'd allow us to see whether
there's been a problem.

> Maybe hiding this code in an #ifdef (i.e. keep it for the old patch
> theory) would be a better option than getting rid of it?

That would depend on how we planned on making the next version of darcs
backwards-compatible.  If we don't make this change, I think we'll probably
have to make the darcs with conflict-handling not be interoperable at all
with older versions of darcs.  Or have an #define that defines whether it
uses new or old patch theory, which seems like a *really* bad idea.

If we make these changes, we can morph the non-conflicting patch theory
into a form that satisfies the new laws.  Then we could possibly make "new"
format repositories readable by an older darcs (but not current darcs), and
"new darcs" could read existing repositories.
-- 
David Roundy
Department of Physics
Oregon State University
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20070808/9faa498c/attachment.pgp


More information about the darcs-devel mailing list