Ben,
Thanks for the offer to help. I set the "svn:externals" property on a
directory via the TortoiseGUI. My expectation is to have that directory
available to me in another location (in the same repo).
Am I correct in thinking that? And if so, do I need to do something
explicit to see the directory in the location where I want it?
When setting the properties, for the URL field, I specified the path where
I expect to directory to be available to me.
This is the output when of the svn propget after I set the values. I am not
clear on what to do or expect next.
C:\>svn propget svn:externals svn://x.x.x.x/bopcs/trunk/system1/cpu
svn://x.x.x./bopcs/trunk//system2 cpu
On Wed, Jan 9, 2013 at 11:40 AM, Ben Johnson <ben_at_indietorrent.org> wrote:
> On 1/9/2013 10:16 AM, C M wrote:
> > Ben,
> >
> > Thanks for the reply. I must admit I don't understand the concept behind
> > "svn:externals" to appreciate how you and others are using it. I need to
> > read the explanation more carefully.
> >
> > The option that I can readily relate to is to possibly treat the common
> > code as a third-party vendor code.
> >
> > Even then it's unclear how to combine in one release both the common and
> > the system-system code.
> >
> >
> >
> > On Tue, Jan 8, 2013 at 11:59 AM, Ben Johnson <ben_at_indietorrent.org
> > <mailto:ben_at_indietorrent.org>> wrote:
> >
> > On 1/8/2013 11:45 AM, C M wrote:
> > > All,
> > >
> > >
> > > I am setting up a new repository and have a question on how to
> handle
> > > “common” code. Common refers to code which is shared across the
> > multiple
> > > systems that we deploy.
> > >
> > >
> > >
> > > In addition to the common code, we also have system-specfic
> software
> > > (custom code).
> > >
> > >
> > >
> > > Given the typical SVN layout, what’s a recommended way to manage
> this,
> > > especially when creating release tags?
> > >
> > >
> > >
> > > In this model, we include the
> > >
> > >
> > >
> > > /trunk/common_version1/application_1
> > >
> > > ../../application_2
> > >
> > > ./../application_3
> > >
> > >
> > >
> > > /trunk/system1/application_1
> > >
> > > ../../application_2
> > >
> > > ../../application_3
> > >
> > >
> > >
> > > /tags/system1/Rel_1 [where this may include the system1 apps plus
> > > common_version1/application_1 and application 3]
> > >
> > >
> > >
> > > ../system2/application_1
> > >
> > > ../system2/application_2
> > >
> > > ../system2/application_3
> > >
> > >
> > >
> > > /tags/system2/Rel_1 [where this may include system2 apps plus
> > > common_version1/application_1, application_2 and application3]
> > >
> >
> > I have similar requirements and have established a layout that works
> > well for me.
> >
> > The "common" code exists in a separate repository and I define
> > references to it where necessary using svn:externals.
> >
> > When I create a release tag, I use TSVN's nifty ability to peg the
> > externals at specific revision numbers; this ensures that the tag
> > contains an exact snapshot of the local ("custom") repository, as
> well
> > an exact snapshots of every external.
> >
> > Does that help?
> >
> > -Ben
> >
> > ------------------------------------------------------
> >
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3041875
> >
> > To unsubscribe from this discussion, e-mail:
> > [users-unsubscribe_at_tortoisesvn.tigris.org
> > <mailto:users-unsubscribe_at_tortoisesvn.tigris.org>].
> >
> >
>
> C M,
>
> SVN Externals are fairly straightforward; they are defined on a
> per-directory basis and are similar in concept to symbolic links on a
> filesystem.
>
> In short, the idea is to define svn:externals on a directory within your
> repository and "point the directory to another repository location". It
> is possible for externals to reference other directories within the same
> repository, or directories in a completely different repository. It is
> also possible to "pin" externals at specific revision numbers, such that
> the directory on which the externals are defined will never be updated
> to a newer revision that the "pinned" revision. This prevents unexpected
> or unwanted changes from creeping into your builds.
>
> If you have more specific questions, please fire away.
>
> Cheers,
>
> -Ben
>
> ------------------------------------------------------
>
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3042169
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_tortoisesvn.tigris.org].
>
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3042780
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-01-11 19:45:04 CET