[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Sparse Directories vs Externals

From: void pointer <rcdailey_at_gmail.com>
Date: Wed, 25 Feb 2009 08:19:53 -0600

On Tue, Feb 24, 2009 at 12:59 PM, David Weintraub <qazwart_at_gmail.com> wrote:

> On Tue, Feb 24, 2009 at 11:17 AM, Robert P. J. Day
> <rpjday_at_crashcourse.ca> wrote:
> > the other reason [for committing to a branch] is that, if you're working
> with Q/A people, and
> > they're trying to certify your software, any change to the code base
> > -- no matter how trivial -- invalidates all their work and they have
> > to start over. so you want to minimize all those picky little commits
> > to the trunk.
>
> Depends on why you're shipping a release off to QA. If you are working
> on a possible release, then by all means branch. This is when you
> should branch. We branch before each release when we have decided we
> have a "release candidate". In that case, we give a build to QA and do
> no changes except for the bugs QA finds. We fix those bugs, give the
> release to QA, then wait for QA again. Meanwhile, we continue to code
> on the trunk.
>
> <snip>
>
> Okay, a bad developer will mess up a project no matter how you do the
> branching, but I haven't seen a great advantage in developing on a
> branch. It seems to add a lot of overhead without giving you much
> benefit. Remember until Subversion 1.5, Subversion didn't have merge
> tracking which made it a poor choice for using development branches.

David, I really love your opinions on branching. I completely agree with
everything.

As far as externals go, how do you feel about those? I think your opinion
would be very valuable.

It seem so far the consensus is that externals are very appropriate for my
specific case. In the past, I've created a python script that used PySVN to
search the current working copy and replace any externals with an actual SVN
Copy and then create a tag out of that. So while our 'trunk' uses externals,
the tags do not. The tags reflect what a working copy would look like. We
did this because if we ever were to have an external that referenced an
outside repository that we had no control over, we wanted to make sure that
a year after the tag was made that the repository didn't somehow get
disconnected. Repositories becoming unavailable is another good reason why
externals should not exist in tags, however when the externals are relative
this is a non-issue.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1227011

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-25 15:20:55 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.