Re: [Gnu-arch-users] Question on --link and commit/update/replay

[Samuel Tardieu]

On  1/01, Tom Lord wrote:

|     > Same questions with update/replay/whatsoever. I can't see anything in
|     > {arch} indicating that "--link" had been used and should be used
|     > again. What did I miss?
| 
| commit doesn't do that automatically because, currently, it has no
| reason to eagerly add the newly committed revision to your revlib.

If something has been checked out with --library (and also --link), I think
an entry {arch}/=library could indicate that the user is willing to work
with a revision library. In this case, a commit could add to a greedy
revision library if it finds one, and link from it if {arch}/=link is
present. If would give an optimal result for a commit.

| Merge commands (update/replay/star-merge/sync-tree) don't do that
| because they can't know without comparing files when it is safe to
| make a link.

I think that "update" can always link before reapplying local changes.
A file with no local change will get a hard link from the library.
If there is a local change, then the commit will make a link from the
library.

"sync-tree" can link logs and such.

In case where {arch}/=link is present, "replay" and "star-merge" could
compare modified files to both sources; since libraries will be used,
all files are local and only modified files will be compared.

| I wouldn't at all mind a new command, `relink', that could be run
| periodically to replace files with links and I can't think of a good
| reason off the top of my head not to consider a --relink option to
| `commit' (treating commit specially since it wouldn't have to compare
| files).

I would prefer not to give lots of options to lots of commands. If I have
indicated that I want a "tla get --link", I think it is reasonnable
to consider that I want to use links in subsequent operations.

  Sam