This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: SVN for src (was Re: Binutils 2.18 prep)
Daniel Jacobowitz wrote:
"svn co" in a checkout creates something completely separate; "svn up"
as I described does not. So commiting worked. But checking out
libiberty and libiberty/config, then committing to libiberty testsuite
from another tree, then svn updating the first tree failed with
'Directory "testsuite" is missing'. A second svn up pulled in the
directory.
I guess that means it's not going to work out this way. Drat.
I thought I tested "svn up <dir>" and it didn't work??? Maybe it's an
svn version thing, or maybe my memory is broken.
Anyway, when I try it now it does work, and I have reproduced your issue.
That gives 3 issues with this approach:
1. "svn up -r"
2. "svn switch"
3. "svn up" when something has changed in a "missing" directory.
I have done a few experiments, and I believe this can all be fixed with
the same set of -N options that were used in the initial "checkout".
E.g. If you checkout with:
svn co svn:...src -N
svn up src/libiberty -N
svn up src/config
then you must update with:
svn up src -N
svn up src/libiberty -N
svn up src/config
and switch to branch/update to revision with:
svn up -r$rev src -N
svn up -r$rev src/libiberty -N
svn up -r$rev src/config
I think the script to do the checkout can be used for all these tasks
and can remove all these issues. That is, provided that the user never
does anything else 'creative'. If the user does their own
updates/switches then the script might to something undesirable.
There is also one other *big* issue, although it may not seem like it
for CVS users. Any directory checked out or updated with -N will cause
newly created subdirectories to be omitted from checkouts, or
conversely, newly deleted directories will be left in (and these effects
will be reversed when the current revision is moved backwards). A simple
solution to this problem would be to limit module selection to top-level
directories only (and then do a full recursive update for each). A more
complex solution would be to have the script recurse over the whole tree
and "deal" with each directory (note that "svn ls" always lists
directories that are "missing"). The script would have to either update
itself first, in order to make sure the set of directories is correct,
or else the module information would have to be encoded as svn
properties on each directory, and thus automatically updated.
All in all, I believe that, even before subversion introduces proper
support for something module-like, it is possible to switch to
subversion, provided that users are prepared to be disciplined in their
use of checkout and update. There will be no need to modify the
structure of the repository (so people who checkout the whole world
still can), and when svn modules are implemented, there will be no
painful transition (of our doing).
Andrew