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

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

[Gnu-arch-users] Re: Partial commit, partial undo


From: Andy Tai
Subject: [Gnu-arch-users] Re: Partial commit, partial undo
Date: Tue, 21 Feb 2006 01:35:54 -0800

On 2/21/06, Ludovic Courtès <address@hidden> wrote:
> But basically, it seems to me that this problem depends on the semantics
> of partial commit.  Suppose this:
>
>   # Pristine tree
>   $ tla mv b c
>   $ tla mv a b
>   $ vi b
>   # ...
>   $ chmod a+x b
>   $ tla commit -x b
>
> What does this `commit' mean?
I would think this (number 4) shoud be the most correct one.  The file
names depend on the state at the time of the commit command.

4. Commit everything but the changes made to the file currently known as
    `b'.
> I'm not sure there exists a general solution to this problem Note
> that the same problem arises with partial undo.
>

So the difficulty arises out of the changed associations between file
ids and file names.  (Are there other operations that cause this
problem?)   Since there is no "correct" solution, I would think the
simplest approach will be to disallow partial commit after renaming
operations.  This can be explained that if you changed the state of
the source tree content, you have to commit the state of the whole
tree.  Implementation wise this can be realized by just adding a new
file in {arch}, something like =renaming_pending, and then the commit
command will not allow just commits of specific files.   This will not
allow partial commits on unrelated files at this time but this
approach is simple.

> A better approach would be to list file IDs instead of file names.  For
> instance:
>
>   $ tla commit -x `tla id b | cut -f 2`
>
> This is much less ambiguous but also less convenient.  Then we could
> assume, in this example, that both data and meta-data modifications
> (including renaming and permissions) are excluded from the commit.  But
> then, in this very example, `commit -x b' would be impossible because of
> the other renaming --- but after all, that is something the user should
> expect.
>
I would prefer the user not to see or to deal with the ids.  This is
too complex, I think, for the task of managing source files.  If I
just want to track  my source file changes, why I want to know the
internal representation of the SCM?

> Conclusion: as a first approach, I'd add a `--ids' option to all the
> selective commands (`commit' and `undo') so that one can specify things
> less ambiguously.
> Then we could also add a `--name' and a `--permissions' option to
> specify that we only want to undo/commit/exclude changes made to the
> name or permissions.  But that is probably less useful.
> Ludovic.
>




reply via email to

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