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.
> 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.
> 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.
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.
---------------------------------------------------------------------
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 07:27:01 CEST