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

RE: Migrating to SVN from zipfile-based archival. Advice?

From: Erik Hemdal <erik_at_comprehensivepower.com>
Date: Thu, 10 Jun 2010 17:51:51 -0400

> -----Original Message-----
> From: Barry Callahan [mailto:barryc_at_rjlsystems.com]
> Sent: Thursday, June 10, 2010 5:26 PM
> To: users_at_subversion.apache.org
> Subject: Migrating to SVN from zipfile-based archival. Advice?
. . . .
> Using the standard layout, I figured the current source would get
> imported under trunk/ and each snapshot should be unzipped and
> imported
> as a tag (eg: tags/release_x).

Hi Barry,

I had to do something similar when we first began using SVN. I had available copies of older revisions of projects, and I used them to modify a working copy, and committed each revision onto trunk, in "date order". I finished up with the "current source" which got committed last.

With appropriate comments, this was an attempt to capture what I had of the revision history. Then I created tags from the various trunk revisions as I went along. It took a bit of work, but preserved what history I could.

If you do this, you need to be watchful when new files are added to or dropped from the project, because you need to "svn add" or "svn delete" them as you go.

> If I understood correctly, unlike, say, RCS, since SVN doesn't version
> individual files, I guess it doesn't matter so much what order things
> get imported in. Right?

If you simply import sets of files straight to a tag, I agree with you. But it would matter if you were trying to capture (or shall I say, recreate) history.

> If I follow this course of action, would I end up being penalized in
> terms of disk usage or performance over some other, preferred method?

Well, you'll need more disk space anytime you can't avoid a cheap copy, such as upon an "svn import". But I'd lean toward getting the files into the repository in a way that makes sense to you, and let disk usage go where it may.

I won't say this is a preferred method, but it worked for me. I had all my files in the repository and I understood what I had done.

> Is the SVN server smart enough to realize that, even if I follow this
> course of action, that
> /trunk/foo/bar.c
> /tags/release1/foo/bar.c
> /tags/release2/foo/bar.c
> are all the same file with minor (if any) differences?

No. If you import files as you described, SVN has no way to capture that two files in different locations with the same name are related. If you first commit to trunk and then make tags, you can set up those relationships. The tags, which are copied from trunk, are "cheap copies" as I recall.

Received on 2010-06-10 23:52:44 CEST

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.