Hi,
I first thought this would be a suggestion, but I now think it's a bug report. It
comes from medium-scale use of SVN at work.
Summary
-------
The current handling of svn:externals allows for an external folder to be
either a fixed revision of the latest (head) revision. The former is good; the
latter I consider wrong for most cases.
I propose that the following formats for lines in svn:externals:
<folder> -r<revision> <URL> ~ fixed revision, as now
<folder> <URL> ~ checkout, &c., fetches the external items at the
repositary revision specified for the
non-external items (changed behaviour)
<folder> -rHEAD <URL> ~ checkout, &c., fetches the latest revision of
the external items (current behaviour for
"<folder> <URL>")
This is necessary when handling simultaneous development of both project files
and common (svn:externals fetched) files.
Reasoning
---------
Consider a development involving some project files (with an svn:externals
property) I'll call "P" and the svn:externals included files I'll call "E";
for both a numeric suffix can indicate files changed at the SVN revision
indicated by the suffix.
* start at revision 1 => P1, E1 (repo. rev.1)
* change P => P2, E1 (repo. rev.2)
* change E => P2, E3 (repo. rev.3)
* change P => P4, E3 (repo. rev.4)
* change E => P4, E5 (repo. rev.5)
* change P => P6, E5 (repo. rev.6)
One fundamental of a version control system (to my understanding) is that it
can reproduce any past version of a fileset on command. Unfortunately, SVN
doesn't do that in the case I've just considered. If the svn:externals
property doesn't have a fixed revision:
* a checkout or export of revision 6 of P is OK - we get P6, E5
* a checkout or export of revision 2 of P is wrong - we get P2, E5; we should get P2, E1
Then, is E is further updated at some future point a checkout / export of revision 6
of P now gets it wrong too.
Current workarounds
-------------------
I know of 2 suggested workarounds:
* always include from tag'd versions of the common files, not a working copy or the trunk
* always include fixed revision files
Neither is applicable in the case I've been working in the last couple of weeks. Work has
progressed broadly in the manner of the example above, except that there have been
something like 100 revisions rather than 6. At this level of activity, anything that
requires the svn:externals properties to be changed for every included file change is
just not viable.
Consider how the above example would look with the fixed-revision work-around ...
* start at revision 1 => P1, E1 (repo. rev.1)
* change P => P2, E1 (repo. rev.2)
* change E => P2, E3 (repo. rev.3), change P's svn:externals property (repo. rev.4)
* change P => P5, E3 (repo. rev.5)
* change E => P5, E6 (repo. rev.6), change P's svn:externals property (repo. rev.7)
* change P => P8, E6 (repo. rev.8)
This is getting messy. The case at work has involved something like 100 revisions in the
last couple of weeks - that would have been unbearable.
Consider also what a checkout / export would do.
* a checkout or export of revision 2 of P is OK - we get P2, E1
* a checkout or export of revision 3 of P is misleading - we get P2, E1;
~ the person may have thought revision 3 would get the changes in E3
The tag workaround is no better - in fact, making a big pile of tags would add yet more
unnecessary hassle.
Hence conclude that there are no satisfactory workarounds with the current svn:externals
handling.
Last word
---------
I very much like SVN - I use it at home and introduced it at work. The problem outlined
above has prevented me using the svn:externals in a situation where it should have been
ideal.
The immediate need has passed, sadly, (unless it's fixed in the next week or 2); I'd
appreciate it if this could be fixed in a 2-4 month timescale as that should catch the
next time the facility may be wanted.
cheers
John Dubery
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 19 00:52:02 2005