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

RE: Re: Maintain Directory Structure When Tagging Files

From: Reedick, Andrew <Andrew.Reedick_at_BellSouth.com>
Date: 2006-07-28 15:59:28 CEST

> -----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

---------------------------------------------------------------------
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:09:19 2006

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.