David James <james82@gmail.com> writes:
> > Subversion working copies could also choose to treat this as a
> > non-error, but then certain classes of genuine errors become
> > undetectable. For a trivial example: if I were to edit my .svn
> > entries file to claim that a file is under version control when it
> > really isn't, today we can -- correctly -- detect that as corruption,
> > but with the proposed change, we could not.
>
> Is this type of corruption common? If your WC claims to contain
> non-existent files, it seems harmless to ignore this incorrect
> information, and treat the non-existent file as an unversioned file.
> Can you think of a use case where this fix would lead to problems?
I think it would lead to problems, although I can't come up with a
concrete example right now.
Think about the big picture: A Subversion working copy stores a
shallow history, just enough to allow some local operations to work
efficiently. But this shallow history is supposed to be a subset of
the deep history stored in the repository. The two are never supposed
to disagree in any important way. Occasionally, and only temporarily,
the working copy may contain a bit of history that the repository
doesn't yet have (e.g., 'svn add'), but we know all of those cases and
we synchronize the histories at commit time.
Now you're talking about changing these basic assumptions. The
working copy would have a bit of shallow history that *lies* -- and
that furthermore cannot be synchronized with the repository. You can
see how this might have major consequences :-).
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 23 22:31:32 2005