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

Re: Managing Vendor Branches

From: Stefan Sperling <stsp_at_elego.de>
Date: Sun, 28 Feb 2010 21:41:09 +0100

On Sun, Feb 28, 2010 at 10:41:52AM -0800, Jeff Mott wrote:
> On Sun, Feb 28, 2010 at 4:28 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Sat, Feb 27, 2010 at 09:09:14PM -0800, Jeff Mott wrote:
> >> I just discovered that using --ignore-ancestry fixed the problem. This
> >> caused SVN to update rather than replace my working copy.
> >
> > What is the ancestral relationship between the branches containing
> > the vendor drops? I assume they are just freshly imported directories?
> >
> > Stefan
> >
> Yes, they are freshly imported directories.

OK that makes sense.

> I found in the SVN book where this behavior is explained
> (http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branchmerge.advanced.ancestry).
> Fourth paragraph under the "Noticing or Ignoring Ancestry" section.
> I only wish they mentioned all this in the Vendor Branches chapter.

If you have time to tweak the text to make it more clear (e.g. by
adding cross-references to other sections) and to send a diff,
I can commit the diff.

The book's source code is pretty easy to understand, it's written
in an XML format called 'docbook'.
See http://svnbook.org for details on how to contribute.

If you really can't make a diff, it's fine if you suggest what should
be changed where so I or others can do it. But a diff would be much nicer
cause it saves those who commit the changes to the book a lot of time (even
if you're only changing a single line), and also because you can easily
send more tweaks in the future (once you're set up, editing the book and
sending a diff is really easy, and the book will improve each time).
Contributions to the book are surprisingly rare, hence very welcome.

Received on 2010-02-28 21:41:58 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.