Yes, good point. I often have libraries checked out that I'm working on
but there are also plenty of cases where you presumably would not want
to be updating them. Definitely need to account for these cases somehow...
Julian
Jay Freeman (saurik) wrote:
> 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
>
>
---------------------------------------------------------------------
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