[ Sorry again for replying so lately. I was somewhat busy lately ]
On Tue, Apr 30, 2002 at 10:47:40PM -0500, Karl Fogel wrote:
> 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?
OK, this are questions which have to be discussed. I think a first
approximation could be to take everything into account what _would_ be
committed by this command if it _were_ changed. (Umm.. wired sentence,
but I think you understand what I am trying to say.
> 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 :-).
I deduce from your reactions that you would not accept such a patch.
For the first step I try to understand why you like current behavior.
Intermixing several modules into one WC seem to be a good reason for
the current behavior. The second step would be to have a concept of a
"project".
Maybe it would be an alternative to leave commit as is and introduce a
new subcommand "commitupdate" or "ciup" or something similar. Is there
any way to make such a transaction atomic?
--
-- Josef Wolf -- jw@raven.inka.de --
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 25 12:19:23 2002