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
Received on Wed Jun 19 22:06:36 2002