[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Some design questions (once more)

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-05-01 05:47:40 CEST

Josef Wolf <jw@raven.inka.de> writes:
> I don't want to eliminate mix-rev's. I just don't want them to come up
> where I would not expect it. While I still can't understand why you
> would want mix-rev's, I have no problem with them if you _explicitly_
> call for them. But they should not come up on _every_ commit.
> PS: Why do you _want_ mixed revisions? What are they good for? Why is
> it good that _every_ commit creates mix-rev's? It seems that I
> have missed some very basic thing.

The problem is that Subversion doesn't know what constitutes "the same
project" in a repository. Is it everything under /? Is /foo one
project and /bar another? Should svn assume interdependency, and thus
be too restrictive sometimes, or should it assume nothing, and
sometimes not be restrictive enough?

We chose the latter way as the default behavior. Subversion does not
know the project-specific semantics of your tree structure, so it
doesn't try to pretend it knows. It simply protects against file
out-of-dateness, because that's what people expect from CVS.

A config option to demand a fully-up-to-date working copy before
commit would be fine. You are the only person calling for it right
now, so you'll understand if we wait for you to provide the patch :-).
All the other developers seem comfortable with the default behavior.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 1 05:46:33 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.