Thank you to Ryan SCHMIDT to have taken the time to read my mail and to have
given a comment.
The concept of working-area-encompassing-several-working-copies did not suddenly
spring out of my own mind, but when you search the 'users' mailing lists for
subject 'Committing Working Copies', you find a lot of wishes on this subject.
For example, see :
- http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=15222
- http://subversion.tigris.org/servlets/ReadMsg?listName=users&msgNo=49494
- Chapter '7.4. Committing across multiple directories' of
http://www.chiark.greenend.org.uk/~sgtatham/svn.html
- The answer below from Gavin LAMBERT
Moreover, from my point of view :
- The biggest consistency problem does not come from disjoint 'working copies',
because the folder containing them is not a 'working copy', and SVN can tell
that to the developer.
- The biggest consistency problem comes from NESTED 'working copies', because
the developer thinks that makes a consistent 'working area', but SVN simply
IGNORES nested 'working copies'.
By the way, I have successfully tested my 'svnWorkingCopy.pl' script on UNIX,
and I have created a 'createWorkingCopyNotConsistent.sh' script for UNIX, so I
attach both.
For me, the most important questions are :
- Don't you think that it is very easy to create an 'working copy' that is
inconsistent of very difficult to manage ?
- Do you think that my 'svnWorkingCopy.pl' script can be useful to detect such
problems ?
- Do you think that my suggested 'best practices' (chapter 4) could be
officially published on the Subversion web site and in the 'Subversion Book' ?
- What do you think of my suggested improvements (chapter 5) ?
Etienne URBAH
From: Ryan Schmidt <subversion-2006c@ryandesign.com>:
Date: Mon, 7 Aug 2006 17:21:20 +0200
> You seem to be making a big deal about something I don't understand
> the purpose of. What's your use case for this working-area-
> encompassing-several-working-copies scenario? I've never seen anyone
> work that way. The way our programmers work is that they check out
> for example the trunk of a project into a single working copy, and
> that's where they work. If the project happens to require other
> projects, they're pulled in through externals. Yes, committing in the
> main project doesn't also commit changes in the external, but the
> external is conceivably used in other projects too, not just this
> one, so it's useful that Subversion makes you take a moment to think
> whether your changes to the external are appropriate for all projects
> that might be using it. It's useful for Subversion to guide the
> developer towards the thinking that they should perhaps first enhance
> the externally-included library to provide some new feature, and then
> in a second (third, fourth, etc.) step modify each project that uses
> the external to make use of the new feature.
From: Gavin Lambert <gavinl@compacsort.com>
Date: Tue, 8 Aug 2006 12:29:09 +1200
> Not sure if this is what the OP was talking about, but it would
> occasionally be useful to be able to issue an 'svn st', 'svn up', or
> even 'svn commit' from a nonversioned folder that happens to contain
> three subfolders that are working copies. (It would also be useful if
> 'svn commit' could commit multiple working copies in a single
> transaction, provided they all came from the same repository --
> currently it refuses to do anything unless everything came from the
> same 'checkout'. But that's a separate issue.)
>
> Mind you, getting nonrecursive checkouts to work properly would handle
> most of those cases.
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
attached non trivial 'svnWorkingCopy.pl' script to find the local root of all
nested 'working copies'. This PERL script works under Windows NT and 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 attached 'createWorkingCopyNotConsistent.sh' script.
This script works under Unix (if line ends are CRLF, you first have to
remove CR with perl -wpi 's/\r//').
If you rename this script with a '.bat' extension, it also works under
Windows NT.
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 have
an option to 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 can post
issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 14 21:40:25 2006