Re: CVS diff and unknown files.

[Sergei Organov]

Paul Sander <address@hidden> writes:
[...]
> What "register adds in the repo" nonsense are you talking about? The
> proposal I made simply requires a contact with the server to run the
> add-time triggers; it does NOT require add-time modifications of the
> repository by the CVS server itself. If the triggers drop turds in the
> repository, then that's a different matter. Also remember that my
> proposal includes a way to shut off the add-time triggers as a client
> configuration, deferring them to commit time to accommodate users like
> you.

Just to understand your point better, do you propose 'cvs add -c
new_file' and 'cvs ci new_file' run exactly the same set of triggers?
Different sets?

> Another point that I would like to make, however, is that CVS can
> become more feature-rich, support multiple policies, and have a
> simpler user interface (in most use cases, at least) all at the same
> time. The problem is that most of us here are too close to the
> implementation to take a fresh view of the problem.
> 
> > In the core CVS program the "cvs add" and "cvs remove" operations
> > must be fixed to be equivalent to "vi file.c" -- i.e. operations
> > which _ONLY_ affect the local working directory and which _NEVER_
> > contact the server.
> 
> See above. If there are no add-time triggers, then I can live with
> what you say. On the other hand, some shops REQUIRE add-time triggers,
> and if add-time triggers are used then contacting the server is
> REQUIRED to make them run.

Sorry, add-time with respect to what? Add-time w.r.t. to working copy is
entirely different from the add-time w.r.t. repository. Do you realize
currently there is no command but 'cvs ci' meaning "add this file to the
repository"? Add time w.r.t. repository currently happens when you 'cvs
commit' the new file. Do you propose to change this?

In fact the semantics of proposed 'cvs add -c' is: "add this file to the
working copy and check if the repository will allow me to commit this
new file if I decide to". In this semantic only the latter part has
anything to do with the repository, and it is "commit", not "add",
that's why I suggested 'cvs commit' would be more logical place to check
for such things.

To get your semantics, it seems you need a new operation with the
semantics "add the file to the working copy and to the repository, but
don't give it to anybody on 'cvs update' yet, until I latter commit the
addition". Do you propose exactly this? How could it be done without
write access to the repository?

> I had hoped that this was clear in the last go-round, but apparently
> not.

For me it is not, sorry. Let me give yet another example. Suppose I've
created a new_file today and have checked it's ok using proposed 'cvs
add -c new_file' command. Two days later what I've checked could already
be wrong (policy change, another user added the same file, etc.). So
there are two questions:

1. How do I repeat my check later? By just repeating 'cvs add -c
   new_file'? This would produce warnings "new_file has already been
   added" that is not a good thing for an operation intended to make
   checks, I'm afraid.

2. Should 'cvs -n ci new_file' run the same triggers 'cvs add -c
   new_file' runs? If exactly the same, then why the duplication?

> > Policy goes above -- it is not hard-coded in the core functionality.
> 
> Agreed. But the tool must be sufficiently flexible to allow robust
> implementations of policies. Sometimes triggers are the right way (and
> wrapper scripts are not), and we've identified one area here where CVS
> is not sufficiently flexible.

That's why I insist CVS should have sane set of elementary operations
that could be then combined in different ways. I have no objection
against "compound" CVS commands that do multiple things (preferably
making them atomic), but existing of corresponding elementary commands
is a must, I believe. Designing tools in a different manner results in a
lack of flexibility, or at least my experience suggests it does.

> >> On Jan 25, 2005, at 9:29 AM, address@hidden wrote:
> >>
> >>> Besides, concerning informing the user about problems ASAP, I find
> >>> myself using 'cvs add' and 'cvs remove' as *late* as possible (as
> >>> close to the commit as possible) due to the oddities in CVS
> >>> behavior described below. Consider the following use-case where
> >>> the intent of tagging is to mark the repository state just before
> >>> committing of a set of changes that includes adding and/or
> >>> removing of some files:
> >>>
> >>> $ cd working_copy
> >>> $ echo a > a
> >>> $ cvs add a
> >>> cvs server: scheduling file `a' for addition
> >>> cvs server: use 'cvs commit' to add this file permanently
> >>> [... time passes ... and now I'm ready to commit...]
> >>> $ cvs update
> >>> ...
> >>> $ cvs tag -F before-my-changes
> >>> cvs server: nothing known about a
> >>> cvs [server aborted]: correct the above errors first!
> >>>
> >>> Oops! Need to remove file back to be able to tag the repository!
> >>>
> >>> Doesn't error "nothing known about a" look funny by the way? Shouldn't
> >>> 'cvs update' show "N" meaning "nothing known" instead of "A" as the
> >>> status of the file then :)
> >
> > No, CVS shouldn't say anything about the unknown file. The tag is
> > being applied to the base revisions of the files in the working
> > directory. A newly added, but uncommitted, file is simply like any
> > other changed file in the working directory and the '-F' should
> > ignore it just as it ignores the changes to files that are already
> > in the repository.
> >
> > I.e. that is a bug, pure and simple.

I consider this to be a bug as well.

> >> But consider this:  "All I want to do is tag my files before I commit
> >> them, and don't concern me with the detail".  Okay, which versions do
> >> you want tagged, the ones that appear in your workspace when you did
> >> the update, or the ones that will appear in the repository when you
> >> commit?
> >
> > That's a nonsensical question.  Tags can only be applied to revisions
> > that are already in the repository.  Tags applied with "cvs tag" always
> > begin with the base revisions that the working directory was created
> > with.
> 
> Remember, I take a user-centric view of the world when I discuss CVS.
> It's frequently said to users that "tags apply to the versions in your
> workspace" when "cvs tag" is used. But after the user has edited a
> file, there are suddenly two possible versions to which a tag might be
> applied. You and I know that the version that gets the tag is really
> the one that's listed in the Entries file, but the user may expect the
> "cvs tag" to create a side-effect in his workspace that causes the
> versions created by a later commit to be tagged.
> 
> In this case, the user needs to be educated. But on the other hand,
> having an atomic commit/tag operation would be useful if it existed...

Well, to tell the truth, all this tagging I do would be not an issue
should CVS support changesets. The tagging in my use-cases is in fact an
attempt to somehow mark a changeset to be able to retrieve it later (in a
form of diff between two tags).

> >> The tag command should be changed to do what you want and expect,
> >> not to force you into some bogus sequence of commands just to
> >> satisfy the tool.
> >
> > The "cvs tag" and "cvs rtag" commands can already do exactly what he
> > wants, and what he expects -- and the ordering of commands is not
> > "bogus", but rather a clear and obvious progression of steps. Things
> > have to be done in the proper order. You can't commit changes you
> > haven't made yet, for example.
> 
> As I recall, the user wanted to perform the following steps:
> 
> cvs update
> cvs rm foo
> cvs tag bar
> cvs commit

More exactly,

1. rm -f foo
2. cvs rm foo
3. cvs update
4. cvs tag bar1
5. cvs commit
6. cvs tag bar2

Unfortunately, this leaves foo without tag bar1 that results in missing
removal of the file foo when I later 'cvs diff' between bar1 and bar2. I
consider this to be a mis-feature.

And

1. rm -f foo
3. cvs update
4. cvs tag bar1
2. cvs rm foo
5. cvs commit
6. cvs tag bar2

doesn't work as (3) re-creates 'foo'.

> The problem was that "cvs tag" was complaining that it could not tag
> the foo file. This is because CVS didn't remember what version it had
> after the rm.

No, it does remember. The CVS/Entries file still contains an entry for
foo along with the version. And it doesn't stop the entire tagging in
this case, -- it just refrains to apply the tag bar1 to the foo and
warns about it. I still believe this is a mis-feature.

> In this case, the user is expecting one of two things: Not tag foo at
> all,

That's exactly what CVS does. I believe this is a mis-feature.

> or apply the tag to the version of foo that was left in the workspace
> by the last update.

That's what it should do, unless -c option is given, I believe. And if
-c option is given, it should probably abort operation, not just warn
about the problem. At least that would be consistent with the current -c
behavior and documentation.

> In both cases, the current behavior of CVS (to complain and exit)

It complains and exists in the case of a new file has been 'cvs add'ed,
not in the case when a file has been 'cvs rm'ed. Exiting on 'cvs add'ed
file when no -c option is given is simply a bug, I think.

-- 
Sergei.