OK, I don't mind the feature being there, but it I would hate it to be the
only way it works (definitely should be an "option" and not just a
"feature"). This happens with CVS rather annoyingly. In our CVS repository
we have a directory called "external" that has an obtain.bat/sh file that
automatically checks out the revisions we need of various external code
sources. This way the process is very automatic, and the revisions we need
(as we slowly bump them forward) get versioned along with the repository.
When we switch to using a new version of APR (for example), I tell everyone
"rerun obtain" and they all get the correct version of APR. Also, if you
check out an old copy, assuming the APR repository is still there, you will
check out the right _old_ version to use with that old code revision.
Well, the CVS command line client likes to place an entry in Entries for the
newly checked out code. This means that when you do:
cvs update -d
On the base of the hierarchy, it follows the update through on the child
working copies. It doesn't affect the code in this case as the children are
sticky tagged at the right date/tag, but it sometimes takes a _long_ time to
process all of the files in, for example, the xerces directory. This isn't
as much of a problem now that Apache finally upgraded their CVS servers last
year, but let's look at this:
cvs update -dPA
That would clear the current repository of sticky tags and get me back to
the HEAD. However, it also does the same to the children... umm... no? I
finally dealt with the whole situation by adding code to obtain.bat/sh to
counter the part of the CVS command line client that adds the entry to
Entries (turns out it leaves a temporary file that is later picked up, easy
to develop an antigen for).
Unless the developers are doing active work on the child repositories (which
I would think would be the pathological case... normally you just use
libraries, you don't develop them), you wouldn't want to be doing update
operations on the children unless you explicitly asked for it, and you would
demand a specific version to be updated to (so all of the developers are on
the same page, can communicate on bugs, and aren't seeing problems in their
code being caused by a developer on an entirely different project).
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
----- Original Message -----
From: "Sander Striker" <striker@apache.org>
To: <dev@subversion.tigris.org>
Sent: Thursday, January 24, 2002 2:04 PM
Subject: RE: Merging and switching
...
> >
> > An argument could be made that if we see an unknown directory, then we
"peek
> > inside" to see if it is a WC (root).
>
> Now _that_ would be cool. Saves you from going into each subproject
> and typing svn up. At least make this an option ;)
>
> > Cheers,
> > -g
>
> Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:59 2006