Either I'm not understanding your response or I'm not explaining this
very well. Whichever is the case, I'll apologize now for being so
thick. Let me try again...
1. I have a product code base that exists in some form on the trunk
2. Once a full release of the product has been tagged and released, I
create a maintenance branch
3. Several bugs are uncovered in the recently released code base that
we choose to release as a hotfix
4. I may or may not branch from the maintenance branch to fix these
bugs, but either way several files in several dispersed locations are
modified and, when all is said and done, the maintenance branch is
updated (either through a merge or direct development)
Once the hotfix has been tested and certified for release, I'd like to
tag only the files that have changed in such a way that I can export
the tagged files to the local directory of my build machine with the
directory structure maintained and no other files exported. In other
words, the export directory on my build machine should only contain
the files and directories that were actually modified.
By doing that, I can create a tarball from the root of that exported
directory structure that can simply be unpacked by customers to
replace the modified files. Easy for me. Easy for them. No overhead
of unmodified files getting in the way.
I hope I've done at least a little better job of explaining exactly
what I'm hoping to do. If it was my understanding of your responses
that was the problem, then hopefully I'll get it next time.
Thanks again.
On 7/28/06, Reedick, Andrew <Andrew.Reedick@bellsouth.com> wrote:
> > -----Original Message-----
> > From: Rob Wilkerson [mailto:r.d.wilkerson@gmail.com]
> > That's not quite what I'm after, so bear with me while I try to do a
> > better job of explaining. What I'm really looking for is a way to
> > facilitate packaging a hotfix that does *not* include the entire code
> > base. What I'd like to be able to do is tag a set of changes, but
> > only include the file structure that is relevant to the modified
> > files. So:
>
> Merging just the hotfix revisions to a branch/tag could work, or at
> least be a good starting point. Worst case you can copy/branch/tag, and
> remove the non-hotfix files from the copy/branch/tag.
>
>
> > differently? That's just the way my maintenance release process has
> > worked - but it's always been a manual effort using VSS. I was hoping
> > svn would help automate it a bit.
>
> Svn is a version control tool, not a change management tool (not a
> bug/defect/ticket tracking system.) Svn's changeset-ish revisions and
> merge-by-revision help in regard, but you still need Something(tm) to
> identify the revisions in the hotfix.
>
> As for alternatives, it depends on your needs. In general the "package
> it all, and deploy it all everytime" method has the advantage of
> consistency, simplicity, and accuracy. There's only process to deploy,
> there's only one process to automate and perfect, and it will almost
> take a fixed amount of time to deploy (easier planning.) Deploying just
> deltas (hotfixes) potentially gives (or just appears to give) you more
> flexibility and speed. However, every deployment is unique, which means
> a much greater chance of errors and a single small error can easily undo
> all the time you saved. (Been there, done that.)
>
> *****
>
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. AL621
>
>
>
--
Rob Wilkerson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 28 17:00:40 2006