gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Re: in-tree pristines fatally wounded (merge-fest etc)


From: Miles Bader
Subject: [Gnu-arch-users] Re: in-tree pristines fatally wounded (merge-fest etc)
Date: 02 Dec 2003 10:51:21 +0900

Tom Lord <address@hidden> writes:
>     > If you use these options with `tla get' will that somehow be
>     > remembered, and reflected in future updates/replays?  If not,
>     > what happens?
> 
> updates and replays will break links of files the modify.
> 
> It has occured to me that perhaps we want a `link-sync' command or
> similar to make a tree as close as possible to a link tree from a
> given library revision.

That would be another `mechanism command'.  It's a bit confusing
because replay and update (especially replay) currently seem tied to
particular mechanisms, but I (and I presume others) often use them
rather more blindly, assuming they have a certain _result_ -- replay
is `make as close as possible to revision X preferring local changes
in the case of conflicts', and update is `make as close as possible to
revision X preferring the revision in case of conflicts'.

If you think of tla as being an end-user tool, it's probably better to
emphasize the result of commands (e.g., making update do `something'
in a hard-linked tree), but if you think of tla as being a low-level
tool then maybe it's better to keep the commands as simple and
straight-forward as possible, even when that's potentially confusing
for a typical user.

Of course the problem is that currently tla's a bit of both, and
lacking the mythical overarch, is the end-user tool by default.

One problem with the `link-sync' approach, is that if you really want
to support hard-linked trees, you'd have to replicate the existing
wealth of tree-modifying commands -- replay, update, star-merge --
with hard-linking versions.  Of course in the presence of conflicts
and tree-local changes, you can't exactly do this precisely, but it
seems desirable to at least keep the tree from drifting away from the
`hard linked state' over time as new revisions are incorporated.

Maybe some sort of post-command `hey these files were updated, here
have a go at unifying them with the library' hook could take care of
this?  This hook could just choose a library somewhere and for those
files that are the same [after updating], replace them with
appropriate hard-links.

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]