> -----Original Message-----
> From: Toby Johnson [mailto:toby@etjohnson.us]
> Subject: Re: Complex VSS Migration - dealing with
> moved/branched version history
>
> FYI, vss2svn is a completely separate project from
> Subversion; I am copying in that mailing list so please join there
> (http://www.pumacode.org/projects/vss2svn) to discuss
> further. See additional comments below...
>
> Bicking, David (HHoldings, IT) wrote:
> > I searched for days for information and tried many options,
> and now am
> > standing at a brick wall.
<snip>
>
> First off, I would take a step back and ask yourself if
> converting and maintaining all that history is really worth
> it. I have seen lots of people (including myself) who
> struggled with migrating a perfect copy of their VSS history
> only to find out they ended up using it much less than they
> anticipated. Particularly in your case I would say it sounds
> like a clean start may be your best option going forward; it
> may be more inconvenient in the short term but after a few
> months you'll probably find yourself needing that history
> very infrequently.
>
> Due to the state of your VSS repo it may be better to simply
> put VSS into read-only mode for reference and then simply
> export the contents and import to Subversion. You'll still
> need to deal with all those shares, since that feature does
> not translate to Subversion, although svn:externals is close
> enough for many purposes.
I totally agree with you, and this might be the decision we make, but I
need to explore all the options first.
>
> > I want to migrate pieces of this behemoth into SVN, but cannot. I
> > used vss2svn to get a dumpfile (12G) and tried to use
> svndumpfilter to
> > grab relevant pieces. Per the state of the data described in the
> > prior paragraph, it fails every time. I found no reference
> to any way
> > to pull a specific project "tree" and get all its history,
> which is quite odd.
> > I would think this would be crucial. Why not permit
> migration to pull
> > the original data into place? A note stating "original
> location is x"
> > should be sufficient.
> >
>
> I'm not sure exactly what you're asking here. If you are
> asking why vss2svn doesn't allow migrating only a portion of
> the VSS hierarchy instead of the whole thing, the answer to
> that is rather technical but in a nutshell the way VSS stores
> its history in "physical files" makes it very difficult to
> convert only a portion of the repo since the program must
> essentially walk the entire VSS tree in order to resolve
> parent-child relationships.
>
> Most people who want to do what you are trying to accomplish
> do use the svndumpfilter approach; if you can provide more
> specific info as to why that is failing then we may be able
> to provide a better suggestion or workaround.
>
> toby
>
>
I did not explain it clearly. I am not asking for vss2svn to do
something it does not. I'm not a member of that group (yet), so I
cannot followup there. My question was directed at the functionality of
svndumpfilter.
I believe a highly useful feature, especially for migration purposes,
would be to "streamline" the data being pulled out of a dumpfile via
svndumpfilter. By streamline, I mean to look at the root path selected,
say "/src/MyProject", trace back through the history, and migrate (copy)
into the specified path any versions located outside that path. Thus,
if two years ago, I copied, shared, or whatevered a file from
"/src/TestVersion3OfMyProject/BusinessObjects" to
"/src/MyProject/BusinessObjects", I might want to be able to pull those
revisions into the filtered dumpfile, too.
This would only happen for those revisions that fall outside the filter
parameters, and only if an appropriate option were set (say,
"--streamline"). For the sake of keeping accurate history, a property
or the revision note would be updated on those revisions to state
something like "this revision was originally in
/src/TestVersion3OfMyProject/BusinessObjects".
It would be nice if tools like vss2svn did this, but I think it is more
effective and useful to include this as a feature of Subversion. It
allows a wider range of utility, and makes it possible for
administrators to break up single bloated repositories into multiple,
more focused ones. Obviously, this amounts to a "heavy copy" of those
revisions (which now reside in multiple locations). I think at times
this is either desireable or not a significantly bad side effect.
--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 16 15:04:21 2007