On May 31, 2008, at 11:21, Laker Netman wrote:
> Ryan Schmidt wrote:
>
>> 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.
I would say: commit all your files. The repository does compress
files, and stores differences quite well, even for binary files, so
long as the binary files aren't themselves compressed. So, for
example, I would expect you to get fairly good space usage in the
repository for committing revisions of an uncompressed TIF file, but
committing changes to a compressed TIF file may not be so efficient.
So, perhaps contrary to usual practice, you should have your art
department save their TIFs uncompressed, not compressed -- after
having done some testing to see if this is really true for TIF files
and for the types of changes you have.
>>> 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.
The history can be maintained. If maintaining the history is
preferable, then do nothing special. Simply dump the entire repo A
and load it into repo B.
Trashing the history of these specific files (but keeping the history
of the rest) is what's difficult.
>>> 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.
Giving it a try is best.
I tried just now, and svn:ignore doesn't do anything during svn
import. svn:ignore is for ignoring items in a working copy, but svn
import operates directly between a local unversioned directory and a
repository; there is no working copy involved, so svn:ignore is not
applicable.
svn import does, however, take into consideration your client's
global-ignores definition.
Nothing will set svn:ignore anywhere for you. Wherever you want it,
you have to set it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-01 07:42:36 CEST