Re: Maintain Directory Structure When Tagging Files

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:

I have a directory structure in which there is a root directory and 5
sub-directories like so:

productroot/
  /sub1
     /file1
  /sub2
     /file2
  /sub3
     /file3
  /sub4
     /file4
  /sub5
     /file5

I modify file3 and file5 and decided to put that out as a hotfix. I
don't want to re-package the entire code base, but I want to maintain
the structure that is relevant to those files. I'd like to create a
tarball for the hotfix such that customers can place that tarball in
their product root directory and simply unpack it and the old files
will be replaced with the modified.

I don't think my issue has as much to do with working within the
repository as it does with extracting subsets *from* the repository.
Does that make any more sense? Are others handling things
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.

Thanks for your help.

On 7/27/06, Ryan Schmidt <subversion-2006c@ryandesign.com> wrote:
> On Jul 27, 2006, at 20:09, Rob Wilkerson wrote:
>
> > I have a project for which I often need to release hotfixes which
> > include some, but not *all* files in the project. The files typically
> > live in different directories scattered throughout the product code
> > base. Is there anyway to tag either:
> >
> > 1. The entire product root, but only so that the changed files are
> > placed in the tags directory
> > 2. Only the files required for that hotfix in such a way that the
> > parent structure (up to the root) is maintained
> >
> > What I want to be able to do is simply export the tag contents and
> > have the requisite directory strucuture created in my build
> > environement.
>
> It sounds like you're coming from the CVS world, where one tags
> individual files. Tags are handled entirely differently in
> Subversion. In Subversion a tag is just a directory in the repository
> to which things can be copied. Files are therefore members of a tag
> in Subversion; a tag is not a property of a file as it was in CVS.
>
> By convention, a tag in Subversion is a snapshot. It should never
> change after it's made. You're talking about applying hotfixes.
> Sounds like you're talking about a branch then, not a tag.
>
> The recommendation would be to have a trunk, where all your
> development occurs, and a branch where just the most essential
> hotfixes can be made. Once you make a change to the trunk that you
> want to have applied to the hotfix branch, you merge that revision to
> the hotfix branch. If you like, you can make tags of the hotfix
> branch at any time.
>
> Have you read about Subversion's branch / tag / merge strategy? It's
> described extensively in the book. You should read the entirety of
> chapter 4:
>
> http://svnbook.red-bean.com/en/1.2/svn.branchmerge.html
>
>
> The other thing you seem to be asking is how to get just the files
> that changed between point A and point B. This request comes up on
> the list every couple weeks. A script could probably be written to do
> this. But there's also a question of why you want this: If you have a
> prior version of the project somewhere and want to update it to the
> current version, then it's very easy to do with "svn up" provided
> what you have is a working copy. If you don't have a working copy,
> then rsync works great for synchronizing two directories with one
> another.
>
>
>

-- 
Rob Wilkerson
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org