Mark Grosberg <firstname.lastname@example.org> wrote on 22.04.2005 20:36:09:
> I would agree that atomic renames is probably the most important feature
> to get out the door next.
IMHO, an additional important thing would be atomic delete+copy. Or atomic
*whatever* to ensure consistent repository states. I mean, doing
(re)structuring work on trunk/ for some operations requires multiple
commits or server-side copies, even if using branches for preparation.
This is not limited to restructuring work, it is also required for local
Think of the following scenario: You have a /repos/libs/trunk/ directory
that should be used in /repos/application/trunk/libs/, but this should not
be accomplished via svn:externals but via local tagging for stability.
This means you do a
svn copy /repos/libs/trunk/ /repos/application/trunk/libs/
or maybe a
svn copy /repos/libs/tags/stable_525/
once (locally or server-side) so that application/trunk/ remains stable
independent from work done on libs/trunk/. If one wants a new version of
libs/trunk/ in application/trunk/, he can either "svn merge" the changes
or simply (and more cleanly) delete the old application/trunk/libs/ and
copy the new version there. But this process cannot be accomplished as an
Note that merging is only usefull if the merged changes are small (no
restructuring, not too infrequent) and the local version is under
development. If no local modification is intended, delete+copy is far
better than merging: Less repository overhead and cleaner repository
operations since you do what you intend to do: delete the old 'tag' and
copy a new one.
For example, deleting application/trunk/libs/ requires a transition from
5->6, and copying libs/trunk/ to application/trunk/libs/ requires another
transition from 6->7. Checking out at 6 brings up an inconsistent
directory state. Not to mention what to do if this change should be
reflected in application/trunk/README, this would be 7->8 if the copy
operation was done as a server-side copy. So, count two inconsistent
directory states. Don't mention what happens if it was not only
application/trunk/libs/ but more directories like
application/trunk/templates/ that would have to be "merged" atomically to
the libs/ update.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Apr 25 11:38:19 2005