----- Original Message ----
> From: Ryan Schmidt <subversion-2008b_at_ryandesign.com>
> To: Laker Netman <laker_netman_at_yahoo.com>
> Cc: users_at_subversion.tigris.org
> Sent: Saturday, May 31, 2008 12:26:29 AM
> Subject: Re: Migrating to a new repository
>
> On May 31, 2008, at 00:11, Laker Netman wrote:
>
> > Ryan Schmidt wrote:
> >
> >> On May 30, 2008, at 08:49, Laker Netman wrote:
> >>
> >>> Ryan Schmidt wrote:
> >>>
> >>>> On May 29, 2008, at 16:26, Laker Netman wrote:
> >>>>
> >>>>> I am preparing to migrate the contents of an existing repo to a
> >>>>> new, empty one. I read the section in the SVN book regarding
> >>>>> filtering repository history (w/svndumpfilter), but I don't think
> >>>>> it does what I need.
> >>>>>
> >>>>> There are a large number of (easily grouped) files, of various
> >>>>> types, that I want *copied to*, but no longer *versioned in*, the
> >>>>> new repository. The svn:ignore property ultimately does what I
> >>>>> want, but how I can go about moving the contents from one repo to
> >>>>> another, making some files non-versioned in the process? Is
> >>>>> there a
> >>>>> method to do this to the existing repo somehow prior to moving the
> >>>>> files? If I set the svn:ignore property to the files I no longer
> >>>>> want versioned in the existing repo will they still copy over to
> >>>>> the new repo (unversioned)?
> >>>>>
> >>>>> Ultimately, I want to keep the rev history from the existing repo,
> >>>>> or I'd just export the files and start over.
> >>>>
> >>>> Ignored files are not stored in the repository. Unversioned files
> >>>> aren't either; that's what unversioned means. So if there are files
> >>>> you don't want in the new repository, you'll have to filter them
> >>>> out
> >>>> of the old repository's dumpfile with svndumpfilter before you load
> >>>> it into the new repository.
> >>>
> >>> Yes, thank you, I understand all of the terminology. Perhaps I
> >>> wasn't clear enough. How do I move *all* files under version
> >>> control in repo A to repo B where
> >>> some files from repo A should still be version controlled and
> >>> others not? I've been experimenting on a test repo. Once a file is
> >>> under version control and then the ignore property is set on it,
> >>> the property has no effect. The file remains under control of
> >>> Subversion. svndumpfilter, from my understanding of the docs, works
> >>> over "time", not repo structure.
> >>
> >> Can you give me an example?
> >
> > Sure.
> >
> >> As I see it, I imagine you have repo A which contains directories 1,
> >> 2, and 3, and you want to migrate everything to repo B except for
> >> directory 2. Then you would svnadmin dump repo A, svndumpfilter it to
> >> exclude 2, and svnadmin load the result into repo B.
> >
> > Say Repo A currently has Directory 1 which contains .TIF and .JPG
> > files, all of which are under version control. Now I want to move
> > Directory 1 to a new repo called B, and I only want .JPG files
> > version controlled, but I want all of the .TIFs copied from A to B
> > as well.
>
> That doesn't make sense to me... If you put a file in a Subversion
> repository, it is version controlled (that is, if you make changes to
> a file, the previous version will still be available). If you don't
> want a file to be version controlled (that is, you want newer
> versions of a file to permanently and irretrievably overwrite older
> versions, such as happens in your normal filesystem), you don't put
> it in a Subversion repository.
Well, it boils down to our business process. When the Art Dept finishes their portion of a project I get their files as hi-res TIFs. I do some final editing, convert the files into one of several different final formats and place those files into the repository. I don't want the TIFs committed, because A) the Art Dept may change something that might or might not affect me, B) I can always re-edit the TIFs I have to create a different final output for my piece and C) I don't want the repo "bloat" caused by committing TIF after TIF. I usually keep the TIFs for a few weeks or months, then just delete them. The same goes for Flash (video) files, and some others that aren't quite so space intensive.
> > Directory 1 may have subdirectories that the same rule would apply
> > to also. All of the directories need to be moved; some of the files
> > will remain versioned, others won't, but still need to be copied over.
> >
> > I re-read svnbook Chapter 3's section on "Ignoring Unversioned
> > Items", and I think I might have found a possible solution. Though
> > the documentation presents the following (seemingly) contradictory
> > information (more like a rule and an exception, I guess). Paragraph
> > 5 says: "And it's worth noting again that, unlike the global-
> > ignores option, the patterns found in the svn:ignore property apply
> > only to the directory on which that property is set, and not to any
> > of its subdirectories." Fair enough. However, the final paragraph
> > includes this: "Subversion uses the ignore patterns—both the global
> > and the per-directory lists [svn:ignore?]—to determine which files
> > should not be swept into the version control system as part of a
> > larger recursive addition or import operation." So, I guess SVN
> > does use a the svn:ignore list set on the root of a repository when
> > doing an initial import?
> >
> > If that's the case, then I should be able to just export Repo A,
> > create an empty Repo B, create an svn:ignore list for the repo
> > root, then do an import?
>
> svn export will lose the existing history. Is that what you're
> getting at? You would like to import dir 1 into repo B and you would
> like to preserve the history of the JPG files but get only the
> current revision of the TIFs and lose their history? If so, you're
> going to have to build a process for that; there's nothing built in
> to mix and match like that.
You nailed it exactly. Losing the old history isn't critical, but if it can be maintained so much the better.
>
> > However, does this automatically create the svn:ignore property
> > (populated with the list of items to ignore) on the subdirectories
> > pulled in from the import (paragraph 5 suggestions it wouldn't)?
>
> No, svn export creates a normal OS directory with the files in it.
> All Subversion metadata is lost in the process, because there are
> no .svn directories in which to store it.
I was thinking on the import side. I'll give it a try and see. Create an empty repo, set svn:ignore and import a directory tree. Based on the docs, I believe the import should honor the svn:ignore on files in the imported subfolders (which will be obvious, if true), but I want to see if the svn:ignore is automatically set on the subfolders as well. If not I'll script something to do it.
>
> Alternative is to use "svnadmin dump -rHEAD" which will preserve all
> metadata. You'll get a dump of only the current version -- but of
> everything. Again you'll have to invent some way to mix and match --
> pull the JPG files out of a full dump and the TIF files out of a HEAD-
> only dump.
>
>
> > I guess I could roll my own property copying tool with Perl and the
> > "svn" command, but it seems like there should be something easier.
>
>
Well, I guess that raps it up.
Thanks,
Laker
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-31 18:21:38 CEST