On 24-Nov-05, at 8:01 AM, Maurizio de Pascale wrote:
> Scott Palmer wrote:
>> svn:externals can be much more painful to deal with than VSS sharing.
>>
>> With svn:externals:
>>
>> -- the access protocol is hardcoded in the externals definition,
>> so even if you get your WC with SVN protocol the external
>> definition might have HTTP protocol. This is a problem when
>> using svn: in the office and svn+ssh from home for example.
>>
>> -- updates are not atomic, each svn:externals link is pulled in as
>> a separate update request, possibly getting a later revision of
>> the repo.
>>
>> -- commits don't dive into the svn:externals links at all. (though
>> I think tortoisesvn DOES do this)
>>
>> -- tagging is painful if you wish to tag the svn:externals links
>> with the main project branch
>>
> Hi Scott,
> Maybe I'm wrong but it seems to me that using the good practice of
> including the revision namber in svn:externals both your point 2
> and 4 are solved.
> Isn't it?
Well if that were possible and truly a "good practice" then yes,
those would not be issues, but then you wouldn't have anything like
the VSS sharing either. I WANT to pull in the HEAD revision of those
bits of shared code - at least that's what I want to do in the trunk.
My situation is this: (simplified)
- I have device drivers and a DLL implementing an API for the device
in one project
- I have a native application that uses the device through the API
- I have a Java application that layers a UI and network services, it
can also talk directly to the native application
These are three projects that must exist independently and yet they
are also all related in that they use services from each other.
I have set up each of these as a separate project in subversion. I
also have a folder in subversion that represents a complete product
comprised of all of these components. It only uses svn:externals to
pull together a build environment for the whole project. (There are
other smaller projects with shared code that support these main
projects are also pulled together into this build environment.)
In the trunk a feature may require changes to all three projects, or
it might be only a change to a single project. Generally though the
trunk build of the main application needs the latest drivers and API,
etc.
The developers that do the device drivers have no dependancy on the
applications that use the device. They don't want to check out all
three projects to work on the device drivers.
The native application has no dependancy on the Java UI that uses it,
so there is no need for the developer of that project to get that
code. In fact the native application only needs a few files from the
public driver APIs, though it uses Microsoft's COM abomination, so it
does need to build the API DLLs in order to compile the app.
Because there are smaller sub-projects that are independent of one or
more of these components, I don't want to put everything under one
folder. (Maybe in non-recursive checkouts worked properly it would
be more feasible?) My strategy has been to make a folder
representing the build environment for a particular collection of
components and pull the needed pieces together with svn:externals.
In any case, it is completely impractical to "pin" the "external"
files at a particular version during development because the pinned
version would change daily to point to the head. Only rarely are
changes made in the driver that require changes to another layer, in
which case for a few hours the head version of everything might not
compile together, but that hasn't been a significant issue.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 24 19:02:53 2005