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/04/25 21:12:14 UTC
Some design questions (once more)
Hello!
I'm very sorry for posting to the wrong list! I hope I get it right
this time.
I wrote:
>> The example in Section 2.2 of the "subversion design" paper and in
>> section 1.2 of the "User Manual" seems to be somewhat wired to me. Why
>> dont all the files get updated to revision 5 after the commit? IMHO
>> such inconsistencies should be created only if one explicitly calls
>> for them (for example by commiting only specified files as in
>> "svn ci write/search.c"). But when "svn ci" (which has the semantics
>> of "commit all changes") is used, the versions of all the files should
>> stay consistent if they were consistent before. IMHO should the effect
>> of "svn ci" be the same as "svn ci; svn update".
From: Ben Collins-Sussman <su...@collab.net>
> If I run 'svn ci', and 3 files are sent to the server, and I create
> revision 10, how on earth would I know that it's okay to label *all*
> of the files in my working copy as being at revision 10? Certainly,
> some of the files I *didn't* commit might have been changed by other
> people between revisions 5 and 10.
As I mentioned in my original mail you would be right if the command
were "svn ci write/search.c". But "svn ci" has the semantics of
"commit everything". In this case the server should refuse the commit,
because the up-to-date-test failed. Please note that my Proposal
explicitly excluded the case where you commit only a subset of files.
>> I understand that
>> committing should be a one-way-operation and should not touch your
>> working files.
> Well, there you go. Commit is a client->server write operation. I
> don't think most people want a commit to be two-way write operation.
> I certainly don't;
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.
> just because I send things to the server, doesn't
> mean I'm ready to start accepting changes.
There are no changes done to your working copy. Only your
administrative files in the SVN-directory are changed. Those files are
changed in either case (at least for write/search.c")!
Having different revisions of the files lying around is a very
error-prone thing and (IMHO) should not be the default-behavior.
> Mixed-revision working copies are a normal thing. They're a normal
> part of life in CVS, so we've kept the same flexibility in SVN.
This is a normal thing in _CVS_. But SVN came up to eliminate some
cvs-issues. So why not eliminate _this_ issue, too? There could be a
configuration option so people could choose which behavior they like.
>> It would be nice to have something like 'char *the_version="$Name$";'
>> and get the tag (_not_ the internal version number but something like
>> "subversion-r909"). The only thing I could find in the docs which
>> addresses this was LastChangedRev, but this seems to be substituted
>> with the internal revision number.
> The tag? Not sure what you want. Perhaps the HeadURL keyword?
> Remember that branches and tags are just ordinary directories
> (locations). $HeadURL$ is the "location" of the file.
This seems to be exactly what I was looking for!
--
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
Re: Some design questions (once more)
Posted by Josef Wolf <jw...@raven.inka.de>.
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 Ben Collins-Sussman <su...@collab.net>.
Josef Wolf <jw...@raven.inka.de> writes:
> Hello!
>
> I'm very sorry for posting to the wrong list! I hope I get it right
> this time.
No worries!
> From: Ben Collins-Sussman <su...@collab.net>
> > If I run 'svn ci', and 3 files are sent to the server, and I create
> > revision 10, how on earth would I know that it's okay to label *all*
> > of the files in my working copy as being at revision 10? Certainly,
> > some of the files I *didn't* commit might have been changed by other
> > people between revisions 5 and 10.
>
> As I mentioned in my original mail you would be right if the command
> were "svn ci write/search.c". But "svn ci" has the semantics of
> "commit everything". In this case the server should refuse the commit,
> because the up-to-date-test failed. Please note that my Proposal
> explicitly excluded the case where you commit only a subset of files.
"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.
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.
It's actually impossible to commit an unchanged file. If foo.c were
unchanged, and you said " svn ci foo.c", nothing would happen.
There's no change to commit. :-)
> >> I understand that
> >> committing should be a one-way-operation and should not touch your
> >> working files.
>
> > Well, there you go. Commit is a client->server write operation. I
> > don't think most people want a commit to be two-way write operation.
> > I certainly don't;
>
> 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. Commits write to the server, updates write to the
working copy. Where is the "error proneness"? 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.
> > Mixed-revision working copies are a normal thing. They're a normal
> > part of life in CVS, so we've kept the same flexibility in SVN.
>
> This is a normal thing in _CVS_. But SVN came up to eliminate some
> cvs-issues. So why not eliminate _this_ issue, too? There could be a
> configuration option so people could choose which behavior they like.
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!
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!
I can't even imagine it as a configuration option: why would people
want to eliminate their ability to have mixed-revision working copies?
> > The tag? Not sure what you want. Perhaps the HeadURL keyword?
> > Remember that branches and tags are just ordinary directories
> > (locations). $HeadURL$ is the "location" of the file.
>
> This seems to be exactly what I was looking for!
Great!
---------------------------------------------------------------------
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:
> As I mentioned in my original mail you would be right if the command
> were "svn ci write/search.c". But "svn ci" has the semantics of
> "commit everything". In this case the server should refuse the commit,
> because the up-to-date-test failed. Please note that my Proposal
> explicitly excluded the case where you commit only a subset of files.
No, the server-side up-to-date test only fails if the *particular*
targets being committed have been changed in the repository. It's
okay for other files, not being committed by A, to have been changed
by B. A's commit will not fail. It doesn't matter if A specific the
targets explicitly or not.
You seem to be proposing that "svn ci" also do an update. That seems
bad, far more unexpected than the current behavior (which was
deliberately designed to match CVS, because we like its behavior in
this situation). Perhaps I'm misunderstanding what you are saying,
though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org