You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Barry Callahan <ba...@rjlsystems.com> on 2010/06/10 21:25:38 UTC
Migrating to SVN from zipfile-based archival. Advice?
I've been using zipfiles to make snapshots of my development
directories. Recently, I've decided maybe a solution that's a little
more robust might be in order, so I'm looking to migrate to SVN.
I'd like a bit of advice on how to go about doing that. Perhaps even
just a sanity check.
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).
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 I follow this course of action, would I end up being penalized in
terms of disk usage or performance over some other, preferred method?
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?
Thanks.
Re: Migrating to SVN from zipfile-based archival. Advice?
Posted by Les Mikesell <le...@gmail.com>.
On 6/11/2010 10:20 AM, Barry Callahan wrote:
> On 06/10/2010 06:24 PM, Lieven Govaerts wrote:
>>
>> All files from svn.collab.net have been copied to svn.apache.org.
>> You're probably talking about svn_load_dirs.pl, which is the tool that
>> the documentation refers to in the 'vendor drop' chapter. You can find
>> it here:
>> http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
>>
>
> Excellent.
>
> I read through the section on vendor drops, and it looks relatively
> straightforward. I'll pull a copy of svn_load_dirs.pl and read through
> it to make sure everything makes sense. From the overview, it looked
> like it might handle adding/removing files automagically, as necessary.
> I may be wrong, but I'll find out when I look at the code.
>
> And I'm assuming that if, in the course of importing things, I find I
> accidentally skipped a snapshot I want preserved, I'll want to check-out
> the snapshot prior to the one I want to import before overwriting with,
> and importing the skipped one.
No, you can't really modify existing history in the repository once it
is committed - you can only go forwards from the last-committed change
(this is sort of the point of revision control). You could copy the
prior one to a branch, then add the changes there but they wouldn't
become part of the history of anything else.
--
Les Mikesell
lesmikesell@gmail.com
Re: Migrating to SVN from zipfile-based archival. Advice?
Posted by Barry Callahan <ba...@rjlsystems.com>.
On 06/10/2010 06:24 PM, Lieven Govaerts wrote:
>
> All files from svn.collab.net have been copied to svn.apache.org.
> You're probably talking about svn_load_dirs.pl, which is the tool that
> the documentation refers to in the 'vendor drop' chapter. You can find
> it here:
> http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
>
Excellent.
I read through the section on vendor drops, and it looks relatively
straightforward. I'll pull a copy of svn_load_dirs.pl and read through
it to make sure everything makes sense. From the overview, it looked
like it might handle adding/removing files automagically, as necessary.
I may be wrong, but I'll find out when I look at the code.
And I'm assuming that if, in the course of importing things, I find I
accidentally skipped a snapshot I want preserved, I'll want to check-out
the snapshot prior to the one I want to import before overwriting with,
and importing the skipped one.
Re: Migrating to SVN from zipfile-based archival. Advice?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jun 10, 2010, at 17:24, Lieven Govaerts wrote:
>>> 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?
>>
>> If you do this you are going to get several copies.
>>
>> What I would do is create a trunk and import the oldest ZIP that you have. Then get a check out of trunk and copy your next version over it. Do and "add" and "commit" then tag it. Continue.
>>
>> Actually, there is a utility that is designed to import ZIPs that are different versions. Although now that everything is at apache.org I don't know where to find all the little utilties that used to be on tigris.org... and they don't seem to be at tigris.org either.
>>
>
> All files from svn.collab.net have been copied to svn.apache.org.
> You're probably talking about svn_load_dirs.pl, which is the tool that
> the documentation refers to in the 'vendor drop' chapter. You can find
> it here:
> http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
Yes, svn_load_dirs.pl is exactly the script you want for this scenario. It's how I initially imported my make-a-copy-every-so-often pseudo-version-control into Subversion years ago.
Re: Migrating to SVN from zipfile-based archival. Advice?
Posted by Lieven Govaerts <sv...@mobsol.be>.
[..]
>> 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?
>
> If you do this you are going to get several copies.
>
> What I would do is create a trunk and import the oldest ZIP that you have. Then get a check out of trunk and copy your next version over it. Do and "add" and "commit" then tag it. Continue.
>
> Actually, there is a utility that is designed to import ZIPs that are different versions. Although now that everything is at apache.org I don't know where to find all the little utilties that used to be on tigris.org... and they don't seem to be at tigris.org either.
>
All files from svn.collab.net have been copied to svn.apache.org.
You're probably talking about svn_load_dirs.pl, which is the tool that
the documentation refers to in the 'vendor drop' chapter. You can find
it here:
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
hth,
Lieven
RE: Migrating to SVN from zipfile-based archival. Advice?
Posted by Bob Archer <Bo...@amsi.com>.
> I've been using zipfiles to make snapshots of my development
> directories. Recently, I've decided maybe a solution that's a little
> more robust might be in order, so I'm looking to migrate to SVN.
>
> I'd like a bit of advice on how to go about doing that. Perhaps even
> just a sanity check.
>
> 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).
>
> 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 I follow this course of action, would I end up being penalized in
> terms of disk usage or performance over some other, preferred method?
>
> 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?
If you do this you are going to get several copies.
What I would do is create a trunk and import the oldest ZIP that you have. Then get a check out of trunk and copy your next version over it. Do and "add" and "commit" then tag it. Continue.
Actually, there is a utility that is designed to import ZIPs that are different versions. Although now that everything is at apache.org I don't know where to find all the little utilties that used to be on tigris.org... and they don't seem to be at tigris.org either.
BOb
Re: Migrating to SVN from zipfile-based archival. Advice?
Posted by Les Mikesell <le...@gmail.com>.
Barry Callahan wrote:
> I've been using zipfiles to make snapshots of my development
> directories. Recently, I've decided maybe a solution that's a little
> more robust might be in order, so I'm looking to migrate to SVN.
>
> I'd like a bit of advice on how to go about doing that. Perhaps even
> just a sanity check.
>
> 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).
>
> 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 I follow this course of action, would I end up being penalized in
> terms of disk usage or performance over some other, preferred method?
>
> 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, importing separately will preserve your snapshots but svn won't have any
concept of the history of any copy. You should probably look at the
documentation related to 'vendor drops' to see the procedure and tools for
handling snapshots that were made outside of version control so svn understands
their relationships.
--
Les Mikesell
lesmikesell@gmail.com
RE: Migrating to SVN from zipfile-based archival. Advice?
Posted by Erik Hemdal <er...@comprehensivepower.com>.
> -----Original Message-----
> From: Barry Callahan [mailto:barryc@rjlsystems.com]
> Sent: Thursday, June 10, 2010 5:26 PM
> To: users@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.
Erik