On Fri, Feb 22, 2013 at 10:33 AM, frame <xsli2_at_yahoo.com> wrote:
>
>>
>> With this approach you loose history of new developments of
>> project/aaa and depend on company B with everything you are doing with
>> project/aaa and which is not already checked out somewhere, because
>> you don't merge any code back into your own repo. It's something which
>> I would consider really carefully.
>>
> Sorry, I don't quite understand what you said. Why will I loose the history
> of new developments of project/aaa? If I modify something in project/aaa and
> I check in, which will be in company B's repo. My partner abroad who only
> cares about project/aaa runs "svn update", he will pull out my change to his
> local area, together with the history. If he makes changes and check in his
> change(to company B's repo), I run "svn update" at the level of project/, I
> will get his new code(in aaa/) together with new code in bbb/ which is from
> company A's repo. I should be able to see his commit hisotry, right?
> I thought this is one of the ideal scenarios exploiting the power of svn
> externals definition.
Do you have write access to the company B repo? If so and you need to
modify that part of the code, externals will do what you want - just
note that commits don't automatically recurse into parts pulled in via
externals, you have to commit them explicitly. The 'vendor branch'
approach is for where you don't have write access and only get
periodic snapshots but want to make it look like a real history. You
can use externals even with just read access to other repositories,
but then you can't commit back directly - but you might be able to
ship patches to someone with commit access.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2013-02-22 17:50:47 CET