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

Reply via email to