Fwd: Advice on handling common code

Oops, it looks like this discussion was accidentally taken off-list.

I'm forwarding back to the list to benefit others and get more input if needed.

---------- Forwarded message ----------
From: Benjamin Fritz <fritzophrenic_at_gmail.com>
Date: Fri, Feb 1, 2013 at 11:56 AM
Subject: Re: Advice on handling common code
To: C M <cmanalyst66_at_gmail.com>

On Thu, Jan 31, 2013 at 11:51 AM, C M <cmanalyst66_at_gmail.com> wrote:
> Hello,
>
>
> My question is more process related with using svn:externals. In my testing,
> it seems that the svn:externals links are bi-directional. Changes are
> instantly propagated via the magic of svn:externals.
>

Where I work, we set up all our svn:externals definitions to point to
a specific revision on a path instead of just a path. This means
changes do *not* automatically propagate to each user of the library.
But the changes can be propagated back to the library.

> 1. How do users preserve the integrity of a tag (which was created off a
> branch which had svn:externals)?
>

Since we use specific revisions in svn:externals, and svn:externals is
a versioned property, checking out a tagged version will likewise grab
the version of the library as it appeared in that tag's svn:externals
definition.

> Does one simply delete the svn:externals link once the tag is created?
>

No, although if you don't specify specific revisions in your
svn:externals, changing the definition to specify a specific revision
is a good idea to do after tagging. In fact, TortoiseSVN recently
introduced a dialog to do this automatically whenever you branch or
tag.

> 2. In the case of common code shared between different projects (link from
> one to many), how are changes to the projects tracked?
>
> Say, projects 1, 2 and 3 all use common code. If project 1 makes changes to
> common (in addition to other changes) and is slated for a release, what now
> about projects 2 and 3? They too must be tagged to reflect the changes? Is
> the the "normal" practice?
>

If each project specifies specific revisions of the library, then each
project would pull in a new library revision only when they are ready
to do so. Unless you feel a need to push out the changes to each
project, you have no need to update the svn:externals or put out a new
release yet.

> It seems like overhead to have to track and tag all projects affected by
> common.
>

Yes, it does add overhead. But it's nicer than having several
independent copies of the same code.

> What are other ways of handling this in SVN?
>

I don't know of any better ways.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3047129

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-02-01 18:59:42 CET