My ISP was being sadistic, so I'm not sure this came through (i
don't see it in the archives)... Sorry if it's a dup!
On Tue, Jan 25, 2005 at 08:13:48 -0500, David Roundy wrote:
> The catch is that to work in the presence of merges, conflicts and
> cherrypicking, the compose and decompose would also need to succeed on all
> input, and that would rule out most useful implementations of the binary
> decomposition.
I'm not sure I follow... Here's how I see it:
* mergeing a conflict:
- user a edits file X in a tarball
- user b edits file X in the tarball
- user a pulls changes from user b
- tarball is decomposed
- patch is applied, but there's a conflict in X
- --external-merge or whatever is applied to X
- given resolution, X is recomposed, and reinserted to
user a's repo, and a merge-patch can be recorded
* cherrypicking - how is this different from pulling? The hunks
simply apply to a sort of meta-file representing the contents
of the binary
Am I missing something obvious? I don't really understand what you
mean by "all input"
What could be painful is conflicts in the decompose/compose
command. This could be worked around by converting decomposing past
revisions of the binary files with the current version and diffing
that.
> --
> David Roundy
> http://www.darcs.net
> _______________________________________________
> darcs-users mailing list
> darcs-users@xxxxxxxxx
> http://www.abridgegame.org/mailman/listinfo/darcs-users
--
() Yuval Kogman <nothingmuch@xxxxxxxxxxxx> 0xEBD27418 perl hacker &
/\ kung foo master: *shu*rik*en*sh*u*rik*en*s*hur*i*ke*n*: neeyah!!!!
pgpcpLVcVVRYu.pgp
Description: PGP signature
_______________________________________________
darcs-users mailing list
darcs-users@xxxxxxxxx
http://www.abridgegame.org/mailman/listinfo/darcs-users
|
