This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]