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/06/19 19:54:47 UTC
Up-to-date-check on commit.
Hello!
On commit svn makes up-to-date-checks only to locally modified
files/properties. What is the rationale for this? IMHO this is
error-prone. Example:
1. Bob$ svn co ; cd wc
2. Joe$ svn co ; cd wc
3. Bob$ emacs foo.c ; make regression-tests ; svn ci
4. Joe$ emacs bar.c ; make regression-tests ; svn ci
5. Sam$ svn export; tar czvf foo.tgz wc; cdrecord foo.tgz
Let's assume the changes Bob and Joe made are inconsistent. In this
case Sam would ship a broken version. I would suggest, that Joe would
be warned about the fact that foo.c in his WC is no longer up to date.
"svn up"ing just before "svn ci" will not help, because it is not
atomic. There is always the risk that somebody else will "svn ci" just
right after your "svn up".
The current behavior to make the up-to-date-check only for modified
files should IMHO be available only if you give svn some sort of
--force option.
Comments?
--
-- 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: Up-to-date-check on commit.
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 20 June 2002 00:38, Branko Čibej wrote:
> What's wrong with "svn st -u"? It tells you exactly what you want to
> know. And we do write the number of the new HEAD revision on commit,
> which you can check, too.
Nothing. I'm fine with the way it works now, and I have no problem with
running 'svn st' and testing before anything is released -- I was just
suggesting a compromise between the guy who wants it to fail the checkin and
those that don't want it to do anything.
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9EZYPNSZCJx7tYycRAkVTAJ98J94JemgBGjNkzhCeTDUX8e3b3wCgqMaZ
E1aVhMRvBrtGuxXs7O+rXAk=
=jTEE
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Up-to-date-check on commit.
Posted by Branko Čibej <br...@xbc.nu>.
Peter Davis wrote:
>On Wednesday 19 June 2002 19:52, Kevin Pilch-Bisson wrote:
>
>
>>I don't want to have to pass --force every time I commit.
>>
>>
>
>The innocent bystander (me) agrees with what a lot of people are saying here.
>Having to pass --force or any other option every time would be a terrible
>pain (I'm hardly ever at HEAD, especially when working on branches), but it
>would also be nice to have a little reminder that I am in fact not at HEAD.
>
>So I propose a compromise: check up-to-dateness for each commit, but make it
>only a WARNING condition if the check fails.
>
What's wrong with "svn st -u"? It tells you exactly what you want to
know. And we do write the number of the new HEAD revision on commit,
which you can check, too.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Up-to-date-check on commit.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Peter Davis <pe...@pdavis.cx> writes:
> Having to pass --force or any other option every time would be a terrible
> pain (I'm hardly ever at HEAD, especially when working on branches), but it
> would also be nice to have a little reminder that I am in fact not at HEAD.
>
> So I propose a compromise: check up-to-dateness for each commit, but make it
> only a WARNING condition if the check fails.
If we were going to do this, we should do it rather as a run-time
config option, you know, something like
# Commits only allowed from completely up-to-date trees.
strict_commits=yes
or whatever. (It's not a huge priority to do, IMHO, just that this
would be the way to go.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Up-to-date-check on commit.
Posted by Peter Davis <pe...@pdavis.cx>.
On Wednesday 19 June 2002 19:52, Kevin Pilch-Bisson wrote:
> I don't want to have to pass --force every time I commit.
The innocent bystander (me) agrees with what a lot of people are saying here.
Having to pass --force or any other option every time would be a terrible
pain (I'm hardly ever at HEAD, especially when working on branches), but it
would also be nice to have a little reminder that I am in fact not at HEAD.
So I propose a compromise: check up-to-dateness for each commit, but make it
only a WARNING condition if the check fails.
--
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Up-to-date-check on commit.
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Thu, Jun 20, 2002 at 12:49:54AM +0200, Branko Čibej wrote:
> Josef Wolf wrote:
>
> >I am using CVS for 10 years now. Because of that I know that some
> >aspects of it are error prone. In real world errors happen when you
> >are in a hurry.
> >
>
> I understand your point, but the fact is that _no_ tool can help you
> avoid the problems caused by bad management. For example, even if
> Subversion warned Joe about Bob's changes, it won't stop Sam from
> picking up a snapshot before Joe's commit. Yes, the tarball will
> compile, but Joe's bugfix won't be in it.
>
As a concrete example, take subversion itself. I often commit with an out of
date tree (well of the times I commit), because I only update once per day
most of the time. I don't worry about it though, since I have seen the svn
commit emails, and can verify with them that no one else has been working on
the same files. I don't want to have to pass --force every time I commit.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Up-to-date-check on commit.
Posted by Branko Čibej <br...@xbc.nu>.
Josef Wolf wrote:
>On Wed, Jun 19, 2002 at 02:59:38PM -0500, Karl Fogel wrote:
>
>
>
>>This method is the very heart of concurrent versioning, at least as
>>implemented by CVS and Subversion. The situation you describe could
>>happen, but in real life, Sam would check to make sure that the
>>exported release works, and Bob and Joe would use a little common
>>sense.
>>
>>
>
>In real life people are not perfect (maybe you are, but I am
>definitely _not_) and make mistakes purposeless. ;)
>
>
>
>>If you haven't used CVS in a concurrent development environment much,
>>you might not realize what a non-issue this is in practice (but I
>>*would* suggest giving it a try before assuming the model doesn't
>>work.. :-) ).
>>
>>
>
>I am using CVS for 10 years now. Because of that I know that some
>aspects of it are error prone. In real world errors happen when you
>are in a hurry.
>
I understand your point, but the fact is that _no_ tool can help you
avoid the problems caused by bad management. For example, even if
Subversion warned Joe about Bob's changes, it won't stop Sam from
picking up a snapshot before Joe's commit. Yes, the tarball will
compile, but Joe's bugfix won't be in it.
Release management is much more than just using version control tools.
The scenario you describe couldn't have happened on my project (which
uses CVS, too), because we put safety checks in the release process that
are designed to prevent exactly such problems. (One such check might be
to compile and test every tarball _after_ it's been created, but
_before_ it's released).
Sure, anyone can circumvent a process, and anyone can trick a tool (want
to know how to make Subversion believe the working copy is up-to-date,
even though there are changes? It's very easy). Preventing that is not
the version control tool's job. It's the project or release manager's
job to make sure that people a) understand the process and the reasons
for it, b) "buy into" the process -- i.e., agree it's a good thing to
follow it, and c) actually follow it.
Being in a hurry is no excuse for making mistakes. You should have
foreseen that you may be in a hurry at some point, and acted to prevent
it. Yes, planning is part of quality assurance! If worse comes to worst,
it's always better to be a day late than to ship a useless product.
(Note to self: Really, I never could understand why people insist on
saying "QA" when what they're really talking about is testing, i.e.,
quality _control_. QC is part of QA; so's planning, project tracking,
reviews, etc. etc. etc.)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Up-to-date-check on commit.
Posted by Josef Wolf <jw...@raven.inka.de>.
On Wed, Jun 19, 2002 at 02:59:38PM -0500, Karl Fogel wrote:
> This method is the very heart of concurrent versioning, at least as
> implemented by CVS and Subversion. The situation you describe could
> happen, but in real life, Sam would check to make sure that the
> exported release works, and Bob and Joe would use a little common
> sense.
In real life people are not perfect (maybe you are, but I am
definitely _not_) and make mistakes purposeless. ;)
> If you haven't used CVS in a concurrent development environment much,
> you might not realize what a non-issue this is in practice (but I
> *would* suggest giving it a try before assuming the model doesn't
> work.. :-) ).
I am using CVS for 10 years now. Because of that I know that some
aspects of it are error prone. In real world errors happen when you
are in a hurry.
--
-- 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: Up-to-date-check on commit.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Josef,
This method is the very heart of concurrent versioning, at least as
implemented by CVS and Subversion. The situation you describe could
happen, but in real life, Sam would check to make sure that the
exported release works, and Bob and Joe would use a little common
sense.
If you haven't used CVS in a concurrent development environment much,
you might not realize what a non-issue this is in practice (but I
*would* suggest giving it a try before assuming the model doesn't
work.. :-) ).
Best,
-Karl
Josef Wolf <jw...@raven.inka.de> writes:
> On commit svn makes up-to-date-checks only to locally modified
> files/properties. What is the rationale for this? IMHO this is
> error-prone. Example:
>
> 1. Bob$ svn co ; cd wc
> 2. Joe$ svn co ; cd wc
> 3. Bob$ emacs foo.c ; make regression-tests ; svn ci
> 4. Joe$ emacs bar.c ; make regression-tests ; svn ci
> 5. Sam$ svn export; tar czvf foo.tgz wc; cdrecord foo.tgz
>
> Let's assume the changes Bob and Joe made are inconsistent. In this
> case Sam would ship a broken version. I would suggest, that Joe would
> be warned about the fact that foo.c in his WC is no longer up to date.
>
> "svn up"ing just before "svn ci" will not help, because it is not
> atomic. There is always the risk that somebody else will "svn ci" just
> right after your "svn up".
>
> The current behavior to make the up-to-date-check only for modified
> files should IMHO be available only if you give svn some sort of
> --force option.
>
> Comments?
>
> --
> -- 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Up-to-date-check on commit.
Posted by Ben Collins-Sussman <su...@collab.net>.
"Stephen C. Tweedie" <sc...@redhat.com> writes:
> Hi,
>
> On Wed, Jun 19, 2002 at 03:03:42PM -0500, Ben Collins-Sussman wrote:
>
> > Josef, you're calling into question the core model of how CVS and
> > Subversion both work... the so-called "concurrent" versioning model.
> >
> > This system is the natural result of not having a "lock-modify-unlock"
> > model. It depends on developers *communicating* with one another.
>
> cvs _can_ do that locking: "cvs watch|edit|unedit|unwatch" deal with
> that (they are listed in the info pages, but apparently not in the man
> pages.)
>
> Nobody I know ever uses these options.
That's because they were stapled onto CVS late in the game, IIRC. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Up-to-date-check on commit.
Posted by "Stephen C. Tweedie" <sc...@redhat.com>.
Hi,
On Wed, Jun 19, 2002 at 03:03:42PM -0500, Ben Collins-Sussman wrote:
> Josef, you're calling into question the core model of how CVS and
> Subversion both work... the so-called "concurrent" versioning model.
>
> This system is the natural result of not having a "lock-modify-unlock"
> model. It depends on developers *communicating* with one another.
cvs _can_ do that locking: "cvs watch|edit|unedit|unwatch" deal with
that (they are listed in the info pages, but apparently not in the man
pages.)
Nobody I know ever uses these options.
Cheers,
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Up-to-date-check on commit.
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Josef,
We long ago decided to behave like CVS in this matter. Period.
Your points are not without merit, but this purely philosophical
discussion is going nowhere as far as Subversion development is
concerned. Please excuse me for not answering the rest of your mail
in detail; it's just not a discussion worth having as we enter Alpha.
-K
Josef Wolf <jw...@raven.inka.de> writes:
> On Wed, Jun 19, 2002 at 05:07:45PM -0500, Ben Collins-Sussman wrote:
> So now you have to tell me why you want to stop this detection on
> file border. Why abort a commit when a _modified_ file fails the
> UTD-Test. Your main argument is that my management is broken. OK, I
> can't convince you about the opposite, because you are right ;-) But
> to some degree your management must be broken, too. Trying to commit a
> modified file which is not up-to-date is a clear sign that there was
> some failure at communications between developers. So why dont you say
> "fix your management instead the tool" in _that_ case? Following your
> philosophy to the bitter end would mean to do automatic merges when
> modified files are not up-to-date because you _called_ for trouble
> instead of fixing your management problems.
>
> Following your philosophy, we could even go a step further and say
> that commits with automated merges (which would happen because you are
> not Up-to-date, see above) should succeed even though there were
> conflicts while merging. Hey, you should fix your management instead
> the tool...
>
> 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.
>
> I dont see any reason for this distinction. As long as we deal with
> textual files (this are 100% of the files in my case, for example),
> there is no reason to assume that two changes in a single file are
> more dependant than two changes in two different files. I think you
> agree with me that the contents of foo.c and foo.h are very close
> related.
>
> > But you're essentially suggesting a dry-run update to execute before
> > each commit, just like 'svn status -u'... and the server gives a
> > warning if your working copy isn't perfectly at HEAD.
>
> The problem is that "svn [status|update]; svn ci" is _not_ atomic. So
> you have no guaranty that you are _really_ at HEAD when committing.
>
> You are "close, but no cigar" ;)
>
> > The truth is, this isn't how CVS works,
>
> This is true and this annoyed me the last 10 years... I had no
> problems with this because I assumed that CVS _could_ not do
> better. And now you say you dont _want_ svn to do better...
>
> > and there's no need to make it Subversion work this way.
>
> OK, you dont see the need. But would it do a harm?
>
> > The rule is just too restrictive: "you can
> > only commit if you're at HEAD."
>
> But you agree to this rule when it is about modified files? Why want
> you to force people to end their horizon at file-border?
>
> > Yes, a --force flag could override,
> > but the issue at stake here is about choosing sensible defaults, and
> > it seems too big a burden to have such a restrictive default behavior.
>
> This could be a configuration option. Best would be if it were on a
> repository basis. This way the repos-admin could decide which policy
> he wants to run.
>
> > I don't want the default behavior to bounce me out or display
> > warnings, because oftentimes there's *nothing* wrong with committing
> > from an out-of-date working copy.
>
> OK, so just put "--force-commits" into your config file. Where is the
> problem? Or (depending of what the default is) just let the
> --i-want-paranoia-commits option out of the config file. It is _your_
> decision if you dont want to see the warning. Why do you want to
> extend _your_ decision to all users of svn?
>
> > (And the situation is rare anyway:
> > 90% of the time, CVS users will 'cvs up' right before they commit, to
> > manually find direct collisions (before the server points them out.))
>
> Hey, this is _my_ point! I dont know about the number, but _you_
> brought the 90% into the game ;-). 90% of the time CVS users
> do "cvs up" because 90% of the time they want to be sure they are at
> HEAD when committing. The trouble is that "cvs up" dont give them
> any guaranty that they are really at HEAD when committing. Remember
> "cvs up; cvs ci" is not atomic. And "svn up; svn ci" is not atomic, too.
>
> > The design of CVS and Subversion is: the tool prevents syntactic
> > conflicts (i.e. overlapping sections of code.) It doesn't prevent
> > semantic problems.
>
> But it still aborts the commit when no overlapping (that is modified
> files without conflicts) occures. So where is the difference?
>
> > It allows mixed-revision working copies...
>
> Which can as well be good as bad.
>
> > which might be semantically wrong.
>
> I think mixed revs are very likely to be semantically wrong. But this
> is just my opinion. Please let us remain on one issue at a time. Will
> go back to the MixRevIssue when the most annoying issues are resolved
> (OK, just kidding (for now ;-])
>
> > It allows HEAD on the server to be a made of mixed file revisions
> > too... which might be semantically wrong.
>
> This can be good or can be bad. Depending on your policies and on your
> management (sigh). You cant judge without knowing the details.
>
> > It's up to the developers to coordinate, test, and tag the correct
> > combinations.
>
> OK, so let us assume all developers agreed to "commit only at HEAD"
>
> > It's philosophically inconsistent to make Subversion
> > behave as though it's "dangerous" to build a mixed, untested HEAD
> > revision.
>
> OTOH it is philosophically inconsistent to make such drastical
> distinctions between file-based and project-based conflicts (note
> that I explicitly avoid the word "module" in this context.
>
> PS: Please excuse me when some of my statements sound rude. It is not
> meant this way. This is mostly because english is not my native
> language, so my vocabulary is somewhat restricted :-8.
>
> --
> -- 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Up-to-date-check on commit.
Posted by Ben Collins-Sussman <su...@collab.net>.
Philip Martin <ph...@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
Re: Up-to-date-check on commit.
Posted by Philip Martin <ph...@codematters.co.uk>.
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.
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.
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Up-to-date-check on commit.
Posted by Josef Wolf <jw...@raven.inka.de>.
On Wed, Jun 19, 2002 at 05:07:45PM -0500, Ben Collins-Sussman wrote:
> We already have conflict detection to some degree. If Joe's commit
> tries to modify the same file that Bob already committed, then the
> server *does* abort the commit, and tells Joe that he needs to update
> first.
So now you have to tell me why you want to stop this detection on
file border. Why abort a commit when a _modified_ file fails the
UTD-Test. Your main argument is that my management is broken. OK, I
can't convince you about the opposite, because you are right ;-) But
to some degree your management must be broken, too. Trying to commit a
modified file which is not up-to-date is a clear sign that there was
some failure at communications between developers. So why dont you say
"fix your management instead the tool" in _that_ case? Following your
philosophy to the bitter end would mean to do automatic merges when
modified files are not up-to-date because you _called_ for trouble
instead of fixing your management problems.
Following your philosophy, we could even go a step further and say
that commits with automated merges (which would happen because you are
not Up-to-date, see above) should succeed even though there were
conflicts while merging. Hey, you should fix your management instead
the tool...
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.
I dont see any reason for this distinction. As long as we deal with
textual files (this are 100% of the files in my case, for example),
there is no reason to assume that two changes in a single file are
more dependant than two changes in two different files. I think you
agree with me that the contents of foo.c and foo.h are very close
related.
> But you're essentially suggesting a dry-run update to execute before
> each commit, just like 'svn status -u'... and the server gives a
> warning if your working copy isn't perfectly at HEAD.
The problem is that "svn [status|update]; svn ci" is _not_ atomic. So
you have no guaranty that you are _really_ at HEAD when committing.
You are "close, but no cigar" ;)
> The truth is, this isn't how CVS works,
This is true and this annoyed me the last 10 years... I had no
problems with this because I assumed that CVS _could_ not do
better. And now you say you dont _want_ svn to do better...
> and there's no need to make it Subversion work this way.
OK, you dont see the need. But would it do a harm?
> The rule is just too restrictive: "you can
> only commit if you're at HEAD."
But you agree to this rule when it is about modified files? Why want
you to force people to end their horizon at file-border?
> Yes, a --force flag could override,
> but the issue at stake here is about choosing sensible defaults, and
> it seems too big a burden to have such a restrictive default behavior.
This could be a configuration option. Best would be if it were on a
repository basis. This way the repos-admin could decide which policy
he wants to run.
> I don't want the default behavior to bounce me out or display
> warnings, because oftentimes there's *nothing* wrong with committing
> from an out-of-date working copy.
OK, so just put "--force-commits" into your config file. Where is the
problem? Or (depending of what the default is) just let the
--i-want-paranoia-commits option out of the config file. It is _your_
decision if you dont want to see the warning. Why do you want to
extend _your_ decision to all users of svn?
> (And the situation is rare anyway:
> 90% of the time, CVS users will 'cvs up' right before they commit, to
> manually find direct collisions (before the server points them out.))
Hey, this is _my_ point! I dont know about the number, but _you_
brought the 90% into the game ;-). 90% of the time CVS users
do "cvs up" because 90% of the time they want to be sure they are at
HEAD when committing. The trouble is that "cvs up" dont give them
any guaranty that they are really at HEAD when committing. Remember
"cvs up; cvs ci" is not atomic. And "svn up; svn ci" is not atomic, too.
> The design of CVS and Subversion is: the tool prevents syntactic
> conflicts (i.e. overlapping sections of code.) It doesn't prevent
> semantic problems.
But it still aborts the commit when no overlapping (that is modified
files without conflicts) occures. So where is the difference?
> It allows mixed-revision working copies...
Which can as well be good as bad.
> which might be semantically wrong.
I think mixed revs are very likely to be semantically wrong. But this
is just my opinion. Please let us remain on one issue at a time. Will
go back to the MixRevIssue when the most annoying issues are resolved
(OK, just kidding (for now ;-])
> It allows HEAD on the server to be a made of mixed file revisions
> too... which might be semantically wrong.
This can be good or can be bad. Depending on your policies and on your
management (sigh). You cant judge without knowing the details.
> It's up to the developers to coordinate, test, and tag the correct
> combinations.
OK, so let us assume all developers agreed to "commit only at HEAD"
> It's philosophically inconsistent to make Subversion
> behave as though it's "dangerous" to build a mixed, untested HEAD
> revision.
OTOH it is philosophically inconsistent to make such drastical
distinctions between file-based and project-based conflicts (note
that I explicitly avoid the word "module" in this context.
PS: Please excuse me when some of my statements sound rude. It is not
meant this way. This is mostly because english is not my native
language, so my vocabulary is somewhat restricted :-8.
--
-- 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: Up-to-date-check on commit.
Posted by Ben Collins-Sussman <su...@collab.net>.
Josef Wolf <jw...@raven.inka.de> writes:
> > This system is the natural result of not having a "lock-modify-unlock"
> > model. It depends on developers *communicating* with one another.
>
> I dont see why I would call concurrency into question. Bob and Joe
> have done their work concurrently. The only thing I am calling for is
> a warning to Joe that his wc is not up to date. Joe could go ahead and
> use the --force flag, so he get the current behavior. But he would
> have the option to abort the commit and check whether Joe's change
> interfere with his change.
We already have conflict detection to some degree. If Joe's commit
tries to modify the same file that Bob already committed, then the
server *does* abort the commit, and tells Joe that he needs to update
first.
But you're essentially suggesting a dry-run update to execute before
each commit, just like 'svn status -u'... and the server gives a
warning if your working copy isn't perfectly at HEAD.
The truth is, this isn't how CVS works, and there's no need to make it
Subversion work this way. The rule is just too restrictive: "you can
only commit if you're at HEAD." Yes, a --force flag could override,
but the issue at stake here is about choosing sensible defaults, and
it seems too big a burden to have such a restrictive default behavior.
I don't want the default behavior to bounce me out or display
warnings, because oftentimes there's *nothing* wrong with committing
from an out-of-date working copy. (And the situation is rare anyway:
90% of the time, CVS users will 'cvs up' right before they commit, to
manually find direct collisions (before the server points them out.))
The design of CVS and Subversion is: the tool prevents syntactic
conflicts (i.e. overlapping sections of code.) It doesn't prevent
semantic problems. It allows mixed-revision working copies... which
might be semantically wrong. It allows HEAD on the server to be a
made of mixed file revisions too... which might be semantically wrong.
It's up to the developers to coordinate, test, and tag the correct
combinations. It's philosophically inconsistent to make Subversion
behave as though it's "dangerous" to build a mixed, untested HEAD
revision.
> > > 5. Sam$ svn export; tar czvf foo.tgz wc; cdrecord foo.tgz
> >
> > If Sam releases a tarball without telling Joe, this is problem with
> > programmers, not with Subversion. :-)
>
> Telling Joe about the release would actually not help. Joe would
> say "I've run the regression tests and they passed. I can give my OK
> to make the release." Hey, Joe "broke the build!"
There are still communication errors.
Bob commits r21.
Joe commits r22. (The two commits do not overlap.)
Bob tells Joe that he wants to roll a tarball.
Joe says "the regression tests passed, go ahead."
What revision are they rolling? Would Bob not notice that HEAD is now
22, instead of 21, when he does a checkout for the tarball? Why
didn't they agree on the revision to roll when they talked?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Up-to-date-check on commit.
Posted by Josef Wolf <jw...@raven.inka.de>.
On Wed, Jun 19, 2002 at 03:03:42PM -0500, Ben Collins-Sussman wrote:
> > On commit svn makes up-to-date-checks only to locally modified
> > files/properties. What is the rationale for this?
>
> Josef, you're calling into question the core model of how CVS and
> Subversion both work... the so-called "concurrent" versioning model.
>
> This system is the natural result of not having a "lock-modify-unlock"
> model. It depends on developers *communicating* with one another.
I dont see why I would call concurrency into question. Bob and Joe
have done their work concurrently. The only thing I am calling for is
a warning to Joe that his wc is not up to date. Joe could go ahead and
use the --force flag, so he get the current behavior. But he would
have the option to abort the commit and check whether Joe's change
interfere with his change.
> > 1. Bob$ svn co ; cd wc
> > 2. Joe$ svn co ; cd wc
> > 3. Bob$ emacs foo.c ; make regression-tests ; svn ci
> > 4. Joe$ emacs bar.c ; make regression-tests ; svn ci
> > 5. Sam$ svn export; tar czvf foo.tgz wc; cdrecord foo.tgz
>
> If Sam releases a tarball without telling Joe, this is problem with
> programmers, not with Subversion. :-)
Telling Joe about the release would actually not help. Joe would
say "I've run the regression tests and they passed. I can give my OK
to make the release." Hey, Joe "broke the build!" The problem is that
Joe is not aware about the fact that his WC is not up to date.
> I'd suggest you read this part of the Design document:
> http://subversion.tigris.org/files/documents/15/17/svn-design.html
> Take a look at the section labeled "Subversion Does Not Lock Files".
I've read this and I dont see the point. I like the concurrency. I am
using CVS for 10 years now and I have _never_ used locks. But again:
my proposal has nothing to do with locks. It's more like:
"foo.c not up to date. Are you sure you want to proceed (yes/no)?"
--
-- 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: Up-to-date-check on commit.
Posted by Ben Collins-Sussman <su...@collab.net>.
Josef Wolf <jw...@raven.inka.de> writes:
> Hello!
>
> On commit svn makes up-to-date-checks only to locally modified
> files/properties. What is the rationale for this?
Josef, you're calling into question the core model of how CVS and
Subversion both work... the so-called "concurrent" versioning model.
This system is the natural result of not having a "lock-modify-unlock"
model. It depends on developers *communicating* with one another.
> 1. Bob$ svn co ; cd wc
> 2. Joe$ svn co ; cd wc
> 3. Bob$ emacs foo.c ; make regression-tests ; svn ci
> 4. Joe$ emacs bar.c ; make regression-tests ; svn ci
> 5. Sam$ svn export; tar czvf foo.tgz wc; cdrecord foo.tgz
If Sam releases a tarball without telling Joe, this is problem with
programmers, not with Subversion. :-)
I'd suggest you read this part of the Design document:
http://subversion.tigris.org/files/documents/15/17/svn-design.html
Take a look at the section labeled "Subversion Does Not Lock Files".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org