Philip Martin <philip@codematters.co.uk> writes:
> Josef Wolf <jw@raven.inka.de> writes:
>
> > Please tell me why do you want commits to abort when _your_ type of
> > communication failure happen (resulting in a commit of a non-UTD
> > file). OTOH you want not even a warning if my type of communication
> > failure (resulting in a non-UTD file which is not modified) happen.
>
>
> Q. Why does Subversion not insist my working copy is up to date before
> a commit?
>
> A. It's not generally necessary. There are lots of things you can keep
> under revision control that have no requirement for a "global
> up-to-date" state. If my repository contains the C.V. for each of
> my employees, or pictures of my children, there is no need to have
> all of them up to date to in my working copy when I commit a change
> to one of them.
Indeed. What if I only check out part of a source code tree? Then
*nothing* can prevent semantic inconsistencies... even if an
up-to-date check is enforced.
> Q. Why does Subversion insist files I commit are up to date? Why
> doesn't it automatically merge?
>
> A. It's not generally possible to merge automatically. Binary files
> cannot usually be merged without special tools. Source code can
> sometimes be automatically merged, but not if the changes conflict.
> Some 'text-like' files cannot be merged at all, suppose the first
> line is the MD5 sum of the remaining lines, an automatic merge is
> likely to produce a 'corrupt' file.
I don't think this exactly answers Josef's main question form his last
mail. If I understand correctly, the question is: "why the
inconsistent behavior that we require up-to-dateness on the files
we're committing, but don't require it of the entire working copy?"
The simple answer is that it prevents you from destroying someone
else's changes to the file... changes that you've not yet seen. It's
part of the general principle of "not losing data". Yes, it's bad
management that this would ever happen, but it's also incredibly
simple for the server to notice during the commit.
(Technically, the first change isn't really lost, as it's under
version control... but without this check, it's very hard to know that
the changes were lost in the first place!)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 24 17:00:14 2002