I have searched for a existing thread on the subject of 'Working Copy
Consistency', but I only found :
- http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html, which
does NOT address consistency,
- the 'Nested working copies' thread, which does NOT address consistency,
- issue 2381 concerning only disjoint 'working copies'.
So I am creating a new thread. Please comment so that I know if my thinking is
relevant and if I should post issues.
The context is the development of one software by several developers using the
same SVN repository or repositories.
1) According to the 'Subversion Book'
--------------------------------------
For the development of this software, a developer can use on his computer a tree
containing several DISJOINT 'working copies'. Each of these 'working copies'
can freely have 'switched folders', 'externals definitions' and nested
(=embedded) 'working copies'.
2) Concept of 'working area'
-----------------------------
But even if the tree created by the developer is not today a concept defined and
managed by SVN, this tree is really something meaningful which I will call a
'working area' : The developer has been assigned a given 'task' (=activity) of
software development, and he uses this 'working area' to achieve this 'task'
with CONSISTENT changes. He builds and tests using the whole 'working area'.
So the developer would expect that :
2.1) his 'working area' stays consistent,
2.2) 'svn status' shows ALL changes inside his whole 'working area',
2.3) 'svn commit' commits ALL changes inside his whole 'working area'.
3) Today's behavior of SVN
----------------------------
3.1) Concerning consistency, that is NOT the case :
3.1.1) With 'svn switch', it is very easy to make several local folders refer
to the same URL.
3.1.2) Externals definitions require a little more work to be used, but the
problem is the same.
3.1.3) Nested 'working copies' can generate the same problem, and they are NOT
even recognized as 'working copies' by 'svn status' !
3.2) Concerning the management of ALL changes inside his whole 'working area',
both commands 'svn status' and 'svn commit' have the same behavior :
3.2.1) They both correctly manage switched folders, and 'svn commit' correctly
fails with an explicit error message when discovering several paths referring
to the same URL.
3.2.2) They both completely ignore 'externals definitions' and nested 'working
copies'.
3.2.3) Furthermore, if the current folder of the developer is a subfolder of a
'working copy', both commands take into account only changes under this
subfolder. If this subfolder is inside a nested 'working copy', it is VERY
DIFFICULT for the developer to find the local root of this nested 'working
copy', even with the 'svn info' command. So it is VERY DIFFICULT for him to
commit ALL the changes of this nested 'working copy'. I had to develop the non
trivial 'svnWorkingCopy.pl' script to find the local root of all nested 'working
copies'. This PERL script works under Windows NT, and should also work under
Unix.
3.3) For an example of a NOT consistent 'working copy', you can create a
'repos1' SVN repository, give write assess to it, publish it with 'svnserve',
and try my 'createWorkingCopyNotConsistent.bat' script. This script works
under Windows NT, and should also work under Unix.
4) Suggested 'best practices'
------------------------------
In conclusion, with the today's behavior of SVN, I think there are severe risks
of inconstancies and incomplete commits in a 'working area', so I suggest
following 'best practices' :
4.1) Before issuing 'svn status' or 'svn commit' commands, always set your
current folder to the local root of the 'working copy'. My 'svnWorkingCopy.pl'
script can help finding the local root.
4.2) Do NOT create or use 'switched folders'. Instead, create and use a
'branch', then merge.
4.3) NEVER create of use nested 'working copies'. NEVER. Instead, create and
use a 'branch' containing all necessary files, then merge.
4.4) Concerning 'externals definitions' :
4.4.1) Contrary to what is written in the 'Subversion Book', do NOT create them
by referring to a revision number inside the trunk (which can change it the SVN
repository is rebuilt), but by referring to the URL of a tag (which has a real
meaning).
'Externals definitions' are tagged by 'svn status' with an 'X' in the first
column, so :
4.4.2) You can freely create and use them for read-only use.
4.4.3) If you modify their content, do not forget to commit them explicitly.
4.5) Try NOT to use DISJOINT 'working copies'. Instead, create an encompassing
project containing the several used disjoint 'working copies', so that any
developer can checkout this encompassing project and get a regular 'working
copy'.
4.6) Do NOT create or use paths referring to the same URL. My
'svnWorkingCopy.pl' script can help discover such paths.
5) Suggested improvements of SVN
---------------------------------
5.1) The information given by my 'svnWorkingCopy.pl' script should be given by
an official SVN command.
5.2) 'svn status' should detect nested 'working copies' and tag them
accordingly, for example with the 'W' character.
5.3) 'svn switch', 'svn checkout', 'svn propset svn:externals' and perhaps
other SVN commands should detect the creation of several paths referring to the
same URL, and then fail with an error message (or at least warn loudly).
5.4) 'svn switch', 'svn checkout', and perhaps other SVN commands should
propagate to 'externals definitions' and nested 'working copies'.
5.5) SVN should take into account the concept of a 'working area' containing
several disjoint 'working copies', and consider it as an encompassing 'working
copy' NOT referring itself to any URL.
Please comment so that I know if my thinking is relevant and if I should post
issues.
Etienne URBAH
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 7 16:26:19 2006