AntC <anthony_clayden <at> clear.net.nz> writes:
>
> Owen Stephens <darcs <at> owenstephens.co.uk> writes:
>
> > The complications arise due to the need to be able to conceptually
consider a
> > darcs repo as a *set* of patches, where the order in which (non-dependent)
> > patches are pulled doesn't matter.
>
> yes I understand a repo is conceptually a *set* of patches, and not a
> DAG [as KevinQ points out]. And yet ... by the time you've commuted a patch
> round to the target of a pull, it might have morphed quite a bit. It has the
> same 'moral effect' but is it the *same* patch??
>
This is how I think of the sameness of patches, but is it too much of a fairy
story? ...
Each primitive patch has:
- an action -- create/delete/modify/move
- a target or location -- directory for a file action, line num for a hunk
-- a move has two locations, source and target
- a content -- file name to create, text to remove/insert (so two contents)
-- a move has null content
Inverting a primitive patch does one of:
- either 'flips' the action -- create 'flips' to delete, etc
- Xor 'flips' the locations -- as with inverting a move
- Xor 'flips' the content -- flips text to insert/remove
Commuting two primitive patches (providing they don't conflict):
- keeps the same action for each
- possibly adjusts the location
- keeps the same content(s)
Does that thinking help understanding? Or does it confuse more?
Perhaps a file copy can't be fitted in to this model? So perhaps a copy should
be seen as non-primitive? I see that inverting and commuting file copies is
problematic(?)
[The Swierstra et al paper has even more primitive actions: a modify is a
combination of primitive delete + primitive insert; a file rename/move is a
delete + create -- but note that the file content is held elsewhere under the
file's id.]
AntC
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
