James McNeill wrote:
> Locking a file only locks it in one place in the repository. If you have a
> trunk and a branch version of a non-mergeable (binary, usually) file, it is
> still possible for people to make changes to both copies simultaneously and
> end up with non-mergeable changes.
Yes, it is.
> Has anyone thought about ways to prevent this from happening?
We run into this working with XSL and DOC files...
> Some branches result in two versions of the same conceptual file, for
> instance if you've got a development trunk and a release branch. Other
> branches are divergences that aren't considered to be the same file, for
> instance if you branch a file to split it into two parts.
> With multiple versions of the "same" file you have the assumption that
> changes will be merged from one branch to another. If the file type does
> not support merging this operation reduces to copying the changed version to
> the other branches.
> In the case of the "same" files in different branches, it seems to me as if
> you'd want a lock on one to prevent anyone from acquiring locks on the other
> versions. Then, if a commit is made on the locked version, the other
> branches would be unable to acquire a lock until they had merged (i.e.
> copied) the change to their version.
> Does this sound logical? Are there deep-seated problems with it? Is this a
> potential enhancement for Subversion?
It is logical. We solved it by moving the doc directory out, like:
/trunk --- dev
and put unmergable files in doc. Then making tags/branches is:
svn cp trunk/dev branches/branch-foo
svn cp trunk/ tags/tag-foo
Things like jar files and other libraries are usually replaced, so merging is not a problem.
Implementing cross-dir locking will be nice though (e.g. symlinks), but might hit performance.
Hope that helps,
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Sep 15 02:17:04 2005