I'm wondering if this plan makes sense to you all. I did a lot of
reading of past comments on the user and dev lists, and we had some
internal discussions, then came up with this.
Background: We're adopting a development strategy that has a lot of
code branches, with parallel development across multiple teams (too many
for manual communication of changes on the same source files) and a lot
of merging. We're concerned about the "no atomic rename" problem,
where a file edit and commit on one branch, and a rename of the same
file (= add + delete, then commit) on another branch, can cause the
first edits to be lost:
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges.bestprac.moves
http://subversion.tigris.org/issues/show_bug.cgi?id=898
(...and discussed in several places I've noted at the end)
(In case someone's interested, here are other places where the 'no
atomic rename' problem is discussed. These might make the following
ideas and question clearer:
http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=64254
http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=42172
http://svn.haxx.se/dev/archive-2006-03/1334.shtml
http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=56041
http://markphip.blogspot.com/2006/12/subversion-moverename-feature.html )
We discussed various approaches (like adding process steps to enforce
communication or caution, having a person or small group "own" code and
approve all changes, etc.), but the overhead seemed high in our
situation.
So our current plan is this: we want to write a script which will:
1) find all branches where a particular file exists (except old ones
where we won't ever merge again).
2) Call N the revision # in which the working copy to be renamed was
last changed in the repository. For each of the branches resulting from
step 1, it verifies that the branch's last-changed revision of the file
being renamed is the same or earlier than N. If it is a later revision,
the script aborts w/ an error and the developer wanting to rename will
either have to do an update or coordinate manually. This way we know
there are no committed changes which risk being overwritten.
3) If that check passes, then the script will lock ALL those copies of
the files, with a comment saying what developer and file names were
involved in the rename. So if someone has changes to that file in their
working copy (say, on another branch where the rename hasn't been merged
in yet), they will get a commit error that the file is locked, and the
lock comment will provide enough information to coordinate properly and
not lose any changes due to the bug. In order to check in their changes,
we would train them to first look at the comment, unlock the file, merge
in the rename from the other branch, then commit their edits. (We'll
have to think some more about what happens when those two branches are
subsequently merged.)
4) we would need to provide a way to "undo" this in case someone decides
not to commit their rename for some reason, and train people to use it,
and be prepared for when they forget.
5) we would leave the locks in place permanently, until someone decides
to unlock, but advisedly.
Ideally, we would do the check and locking in a single transaction, but
even if there is no way to specify that, it's still much safer than we
were before.
Maybe later on, we can semi-automate the task of unlocking and properly
handling changes to renamed files, when there are many to merge back to
our main code line, but we'll get to that issue later. First we want to
verify conceptually that we're on the right track.
We know we need to test out all these scenarios and see what we can break.
BUT: Does anyone see potential problems with our approach? Or, is there
something better out there we should be looking at trying? Any suggestions
at all?
(We have discussed hiring someone to simply fix but #898 for us, but we
don't know how well my employer will go for it, or how much it would
cost. This workaround may or may not simplify things in the meantime....)
Thoughts??
Thanks!!!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 11 20:57:38 2007