Ben Collins-Sussman <sussman@newton.ch.collab.net> writes:
> Instead, svn treats adds and deletes like any other local mods -- it's
> just a local mod on a dir, instead of a file. At commit time, you'll
> get tree-structure conflicts along with your textual ones.
>=20
> Or, look at it from the other direction: suppose 'svn add' immediately
> checked the repos for tree conflicts. Then for consistency, 'svn cp'
> and 'svn mv' and 'svn rm' would all have to do the same. Isn't this
> going a bit too far?
Actually, I think Kevin's reporting a local inconsistency, which the
client should indeed detect.
For example, on a commit, it would be meaningless for a client to
report text deltas against a file that doesn't exist in its base
revision. It would be meaningless to call `replace_dir' on an entry
that doesn't exist. These aren't conflicts between commits: they're
operations being applied in ways that don't make sense. They suggest
that the client is confused about the state of its base revision.
If a client allows an `add' when the file is already under version
control, that seems wrong --- forget conflicts with other commits,
this operation just doesn't make sense in the context of your base
revision. Allowing such an `add' without comment suggests that the
next commit will try to do an `add_file' on a directory entry that
already exists. That's not a conflict --- that's simply incompatible
with your own base revision, which you supposedly know.
Received on Sat Oct 21 14:36:26 2006