Re: Merging and switching

Julian Fitzell wrote:

> 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...

This is trivial in SVN -- you just check out a tag, then no amount of
updating will pull in any changes. Yes, subversion has automagically
built-in sticky tags, called directory copies. :-)

> 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
>

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org