Hi Florent,
Thanks for your input.
Florent Becker wrote:
Nik <darcs <at> babel.homelinux.net> writes:
I'm not too fan of that idea, since it means making darcs' patch theory more
complex, while we all praise its simplicity.
That's disappointing. I was fairly confident that the idea wouldn't add
much (or inded any) to darcs' patch theory. I thought that it was just a
management operation (hold a number of patches as a single entity in the
repo) rather than a patch theoretic operation.
Is it possible for you to outline briefly why this operation would
impact the patch theory? Or failing that, point me towards some more
in-depth documentation that would explain it. From what I've read on the
website, I couldn't see any impact on the patch theory, I'm sorry.
Are you saying that to implement such a new type of patch would make the
patch theory more complex?
What you can do is name all your
small-scale patches with some keyword such as [minute] or [draft]. Then whenever
you want to work at coarse scale, you use --match "not name [minute]" together
with --dont-prompt-for-deps (ie, you put that in the _darcs/preferences of the
coarse repo). This has the result of letting you select the "real" patches,
while hiding the detail patches.
I will test doing it this way.
With the current implementation, there is the slight drawback that you cannot
see the detail of the small patches (hitting 'v' in patch selection shows
nothing). All you need to make that drawback go away is to add a "show this
patch dependencies" action in patch selection.
I think that this allows to have your coalesced patches with only UI logic and
no changes in darcs' core.
When you say "with only UI logic", are you referring to changes to the
"push" and "pull" commands that would automatically perform the tasks
required to coalesce?
So if I'm understanding you correctly, you are suggesting modifying the
pull and push commands to recognise the coalesce (or unify or whatever)
option that:
* adds a keyword such as "fine" to the names of the fine-grained patches
being coalesced;
* ensures that the receiving repo has the "not match [fine]" in the
preferences;
* adds an additional patch to the course repo that depends on all the
fine patches that have just been pushed;
So now if a user views the coarse repo, then patches with the "fine"
keyword are hidden; and the coalescing patches are visible and have
useful names that the user can pull.
I must admit this is the structure within the repo that I originally
considered. I thought people wouldn't like it, so I suggested the new
patch type because it was a conceptually cleaner solution.
Q: I presume that because the coalescing patch depends on the
fine-grained patches, darcs will stop or at least try to stop users from
accidentally obliterating one of the fine-grained patches that the
coalescing patch depends on?
Q: Is there some way to avoid overlaps between user-selected names and
the "fine" keyword?
Q: Would all of this be easier if darcs made spontaneous branches more
corporeal - ie, the information about a spontaneous branch were stored
somewhere other than in the patch name?
Thanks again for your input.
Cheers!
Nik
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
