You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Josef Wolf <jw...@raven.inka.de> on 2002/05/01 00:20:35 UTC
Re: Some design questions (once more)
On Thu, Apr 25, 2002 at 04:35:21PM -0500, Ben Collins-Sussman wrote:
> "svn ci" doesn't mean "commit everything in the working copy". It
> means "commit all files that have been changed". There's a huge
> difference. And this is what it means in CVS as well, which is why we
> kept the semantic.
I wrote "commit everything" and had in my mind "commit all changes". I
see I have to be more accurate in the future :)
> When you run "svn ci" (or "cvs ci"), a process actually crawls your
> working copy and looks for files that have been modified, and only
> commits those files.
Yes, that is what it does by now. And this is exactly what bothers
me.
> > This is your point of view, which I can understand. On the other side,
> > such inconsistencies are very error-prone and I don't think most
> > people want error-prone behavior by default.
>
> This isn't just my point of view: it's a whole paradigm brought to us
> by 10 years of CVS.
OK, but if you want an exact copy of CVS then you have to expalin why
the subversion project exists. AFAIK subversion tries to make some
things better than cvs. AFAICS it actually does _much_ better. CVS
could not do better, because it relies on the file-based RCS. But SVN
_could_ do better because svn is no more file-based but module-based.
But for some reason you don't _want_ it to do better. Ummm...
> Commits write to the server, updates write to the
> working copy. Where is the "error proneness"?
OK, so let me give you an example how this could fail:
1 user1$ svn co # get revision 5
2 user2$ svn co # get revision 5, too
3 user1$ emacs foo.c
4 user2$ emacs bar.c # let's assume the changes made are inconsistent
5 user1$ svn ci # create revision 6
6 user2$ svn ci # create revision 7
Revision 7 will be broken because the changes are inconsistent. IMHO
there should be at least a warning when rev7 is committed. There
will be even more trouble if user2 creates a branch and forgets
the "svn update" before creating the branch. Bar.c will be branched
from revision 7 and all other files (including foo.c) from revision 5.
For sure, you can avoid these errors if you are perfect and all your
co-workers are perfect. But people make errors. They simply _forget_
to "svn update". They simply forget to warn/inform other people about
commits. They simply forget to check whether they were other
commits. When you are in a hurry, you just dont _want_ an error-prone
behavior by default.
> When a user updates,
> they know that they'll only be receiving changes. When a user
> commits, they know that they'll only be sending changes. Blurring the
> behaviors leads to much more unpredictability, I think.
You misunderstood me (is my english really _that_ bad? ;-). I never
mentioned that your working files should be changed on a commit. Only
the administrative files would be changed.
The changes I am proposing are:
1.) (dependant on a config-option) refuse commits if _any_ file fail the
up-to-date-test. This is to make sure your working files will not be
changed in step 2. (OK, I did not include this in my original post)
2.) (dependant on a config-option) give an automatic atomic update
after a commit. Because of step 1.) this won't do any changes to
your working files.
> Sorry, I don't see the "issue" here. I don't believe that
> mixed-revision working copies are a design flaw in CVS. It's actually
> a useful feature that people depend on!
Ummm... I'm using cvs for 10 years now, and I still have no idea what
this "feature" could be good for. Could you give me an example? The
only times I used this "feature" were when I had to to correct the
errors which were caused by this "feature".
> Quite often, people want to backdate files in their source code tree,
> or move whole subdirectories to different branches or revisions. If
> you forced users to *always* have a working copy that resembled some
> pristine tree on the server, I daresay the users would revolt!
If this were a conf-option there would be no reason to revolt. Just
configure it the way you like it.
> I can't even imagine it as a configuration option: why would people
> want to eliminate their ability to have mixed-revision working copies?
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.
--
-- 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
Re: Some design questions (once more)
Posted by Josef Wolf <jw...@raven.inka.de>.
[ Sorry for replying so lately. I was somewhat busy lately.. ]
On Tue, Apr 30, 2002 at 10:50:28PM -0400, Garrett Rooney wrote:
> On Wed, May 01, 2002 at 02:20:35AM +0200, Josef Wolf wrote:
>
> and honestly, the statement that we are 'module based' rather than
> 'file based' is pretty much completely false. SVN has no concept of
> modules at this time at all, although it may in the future.
I meant "module based" not the way CVS understands modules. I think I
had better be used "project based". Svn have one revision for the
whole directory tree while cvs has its own revision-tree for every
single file.
> it does
> version things other than files (directories specifically, and
> eventually symlinks), but that's not the same as being module based.
> actually, to be entirely accurate, SVN versions tree structures
> (directories and the files they contain).
This is exactly what I tried to express. Since svn versions tree
structures the default behavior should be to avoid inconsistencies
withhin this structure.
--
-- 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
Re: Some design questions (once more)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Wed, May 01, 2002 at 02:20:35AM +0200, Josef Wolf wrote:
> OK, but if you want an exact copy of CVS then you have to expalin why
> the subversion project exists. AFAIK subversion tries to make some
> things better than cvs. AFAICS it actually does _much_ better. CVS
> could not do better, because it relies on the file-based RCS. But SVN
> _could_ do better because svn is no more file-based but module-based.
> But for some reason you don't _want_ it to do better. Ummm...
the stated goal of the subversion project is to build a revision
control system that follows as closely as possible the style that CVS
provides, while correcting as many of the more grevious problems with
CVS. in the future, we may explore some functionality that isn't
present in CVS, but overall, the general development style that CVS
provides for has proven to be quite usefull, and we feel that sticking
to it is a good thing.
and honestly, the statement that we are 'module based' rather than
'file based' is pretty much completely false. SVN has no concept of
modules at this time at all, although it may in the future. it does
version things other than files (directories specifically, and
eventually symlinks), but that's not the same as being module based.
actually, to be entirely accurate, SVN versions tree structures
(directories and the files they contain).
-garrett
--
garrett rooney Remember, any design flaw you're
rooneg@electricjellyfish.net sufficiently snide about becomes
http://electricjellyfish.net/ a feature. -- Dan Sugalski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some design questions (once more)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Josef Wolf <jw...@raven.inka.de> writes:
> > 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.
No, I wasn't being sarcastic. I would have no objection to this
behavior, as long as it were optional (set in the config files), and
not the default.
I can't speak for others, of course. The patch might get voted down,
just not by me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Some design questions (once more)
Posted by Josef Wolf <jw...@raven.inka.de>.
[ 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
Re: Some design questions (once more)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
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.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org