Stefan Schwarzbach wrote:
> Kalin KOZHUHAROV schrieb:
>> The exact place to look for this is:
> Thanks for the answer. I already knew about the svn:need-lock property.
> We don't have problems with files that have that property, because of
> the read only state and the must to lock it before editing.
> My problem lies in the files that are mergeable (f.e. text files).
> Client A knows that most of the file (for example a c++ source) is not
> useable anymore. So he locks that file because he wants to completely
> rewrite that file from the ground up, so that a merge (of another change
> of client B) would have no sense. But client B does not recognize this,
> because the file has no svn:need-lock property.
Well, I don't think that is "the right way" to develop code anyway. Even
for developers coming from M$ world, trying to be more consistent and
introduce gradual changes might help. What you suggest here is not
solvable in subversion alone, I think. It comes to project management.
Aaand, how long does it take to rewrite completely something? More than
a few hours, I guess.
And how many commits? No, please don't say your devs are making complete
rewrites in one single commit! Mine used to :-), but we changed that
very bad practice by working with branches.
> Is there any solution? The only way I can solve it now is to inform all
> developers in another way that this file is locked for now.
Inform in another way is the best anyway.
Apart from that, make a practice that everyone updates their working
copy often. At least before starting to edit another file. Then the
developer to introduce the rewrite does:
svn propset svn:needs-lock the_file.cpp
svn commit -m "Preparing the_file.cpp for rewrite.."
svn lock the_file.cpp -m "Completely rewriting the_file.cpp, contact me
if you have questions."
svn commit --no-unlock the_file.cpp -m "not yet :-("
} until test_pass();
svn commit the_file.cpp "YES! I did it!"
And everybody should be happy.
Yet another way is to use branches( somebody can still edit the trunk
and loose time, but anyway, the "rewriter" may not succeed to rewrite
the file, so s/he can just abandon the branch).
Yet another way is to delete the original file and rename it for the
time of editing (bad).
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Sep 3 13:15:00 2005