Is it safe to say that nobody has an answer or suggestion concerning my
questions below? Nobody has any insight into the plans or perceptions of
the Subersion developers concerning migration of projects with checkered
histories?
> -----Original Message-----
> From: Bicking, David (HHoldings, IT)
> [mailto:David.Bicking@thehartford.com]
> Sent: Thursday, August 16, 2007 9:06 AM
> To: users@subversion.tigris.org
> Subject: RE: Complex VSS Migration - dealing with
> moved/branched version history
>
> > -----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 Mon Aug 20 21:33:34 2007