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

Handling non-sequential vendor releases

From: Ryan Lange <ryan.m.lange_at_gmail.com>
Date: Wed, 29 Aug 2012 16:02:40 -0400

Hi all,

I've been thinking up a repository structure for some personal projects
that I am planning. These projects are extensions for a third-party
application, so, naturally, I want to keep versions of this third-party
application in a vendor branch so that they're available to test against.

    - vendors/
         - VendorA/
             - 1.0.0/
             - 1.1.0/
             - current/(identical to 1.1.0)

The issue that occurred to me is that this vendor is known to release
versions "out of order" due to important bugfixes. Meaning, it's
possible for them to release v1.0.1 /after/ they've released v1.1.0.

I think this a fairly common situation, but the usual method of
importing to current (with svn_load_dirs or an equivalent) and then
tagging seems to break down here, at least in my mind. My first thought
was to keep separate "current" directories for each minor release, like so:

    - vendors/
         - VendorA/
             - 1.0.0/
             - 1.1.0/
             - current-1.0/(identical to 1.0.0)
             - current-1.1/(identical to 1.1.0)

But that seems a bit much.

Another thought was to simply branch the most recent release in that
minor release, like so:

    - vendors/
         - VendorA/
             - 1.0.0/
             - 1.0.1/ (branched from and currently identical to 1.0.0)
             - 1.1.0/
             - current/ (identical to 1.1.0)

Now, instead of importing the vendor's 1.0.1 package into current, I
would import it into 1.0.1. This seems like a much cleaner solution to
me, but I'm always afraid that there's something I'm missing. Can anyone
see anything wrong with this solution? Is there a better way?

Thanks in advance,
Ryan
Received on 2012-08-29 23:50:00 CEST

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.