You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@red-bean.com> on 2006/10/02 16:44:23 UTC
Re: feature request: append to last commit
Unfortunately, this proposal goes against a fundamental design
principle of subversion -- tha revisions are immutable.
Suppose you commit revision 90, and then do a 'amendatory' commit to
revision 90 a couple of minutes later. But suppose somebody else did
an 'svn update' to r90 during that two-minute window. Now their
client has a different definition of r90 than somebody who runs 'svn
update' *after* the ammendatory commit. The former working copy is
going to get a big checksum error when the try to update to r91 later
on.
If you're really worried about having the code always be in 'perfect'
state, then use branches. That's what they're for. Let the trunk be
unstable, and then port ranges of commits to a 'stable' branch
whenever the trunk is consistent. This guarantees that the branch
will *always* be stable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: feature request: append to last commit
Posted by ho...@mercatis.com.
Ben,
thanks for your reply. I was aware of the potential consistency
problem, that'd occur, if sombody "did an 'svn update' to r90 during
that two-minute window". Thus I'd proposed to allow it only, if there
was no read access meanwhile.
However, you're right. Branching is an alternative!
Regards,
Holger
Quoting Ben Collins-Sussman <su...@red-bean.com>:
> Unfortunately, this proposal goes against a fundamental design
> principle of subversion -- tha revisions are immutable.
>
> Suppose you commit revision 90, and then do a 'amendatory' commit to
> revision 90 a couple of minutes later. But suppose somebody else did
> an 'svn update' to r90 during that two-minute window. Now their
> client has a different definition of r90 than somebody who runs 'svn
> update' *after* the ammendatory commit. The former working copy is
> going to get a big checksum error when the try to update to r91 later
> on.
>
> If you're really worried about having the code always be in 'perfect'
> state, then use branches. That's what they're for. Let the trunk be
> unstable, and then port ranges of commits to a 'stable' branch
> whenever the trunk is consistent. This guarantees that the branch
> will *always* be stable.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org