You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Yerra Babji <yb...@gmail.com> on 2016/06/20 11:07:48 UTC
Which is the best tool /process to migrate VSS (with history) to Subversion
Hi,
I am looking for best tool / process to migrate VSS folders (with history )
to Subversion.
Thanks in advance for your suggestions.
Thanks,
Babji
Re: Which is the best tool /process to migrate VSS (with history) to Subversion
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jun 21, 2016, at 11:44 PM, Branko Čibej wrote:
> On 20.06.2016 15:04, Nico Kadel-Garcia wrote:
>> Unless you have a compelling need for history, I'd suggest you do a
>> simple export o a working copy from VSS to a simple export in
>> Subversiont.
>
> I have to say I'm mildly put off by your repeated suggestions on this
> list to throw away history to make things "easier" during migrations.
Me too. When a person asks how to migrate with history, I don't like seeing a response that says don't migrate the history.
I am currently in the process of testing a migration of a Subversion repository with 14 years of history (which has previously been migrated from CVS) to a different VCS. Yes, I am preserving all the history. Yes, I am removing cruft during the conversion as well. Yes, a proper conversion can take some effort. Yes, it's worth it.
But I don't have any experience with or advice for converting to VSS.
Re: Which is the best tool /process to migrate VSS (with history) to
Subversion
Posted by Branko Čibej <br...@apache.org>.
On 26.06.2016 16:49, Mark Phippard wrote:
> The issue is that a lot of VSS repositories have hidden corruptions
> that do not surface until you try to migrate the history. It seems
> like the corruptions are often in the history or something, so it is
> only when you start trying to extract old data that it surfaces.
The reason for that is that the architecture of VSS requires that every
user has write access to the actual repository databases; these are just
files in a shared folder, and VSS assumes that CIFS locking is
sufficient to implement distributed transactions. Since that's not the
case, there's no way to avoid silent corruptions.
Back in the day I administered a VSS repository used by a team of some
20 or so developers ... fixing corruptions was a regular daily task.
-- Brane
Re: Which is the best tool /process to migrate VSS (with history) to Subversion
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Jun 22, 2016 at 12:44 AM, Branko Čibej <br...@apache.org> wrote:
> On 20.06.2016 15:04, Nico Kadel-Garcia wrote:
> > On Mon, Jun 20, 2016 at 8:45 AM, Stefan Hett <st...@egosoft.com> wrote:
> >> On 6/20/2016 1:07 PM, Yerra Babji wrote:
> >>> Hi,
> >>>
> >>> I am looking for best tool / process to migrate VSS folders (with
> history
> >>> ) to Subversion.
> >>>
> >>> Thanks in advance for your suggestions.
> >> 7 years ago when I migrated VSS to SVN in our company, I used this tool:
> >> http://vssmigrate.codeplex.com/
> >> Had some issues, but it turned out to do the job quite well (check out
> the
> >> reported issues there - think I reported everything I ran into back then
> >> which wasn't reported already).
> >>
> >> 7 years is quite a while ago. So maybe nowadays there are better
> solutions
> >> available. Just google and see if you find a more mature product out
> there.
> >> vss2svn seems to be suggested quite often and there also seems to be an
> >> commercial importer available from Polarion.
> > Unless you have a compelling need for history, I'd suggest you do a
> > simple export o a working copy from VSS to a simple export in
> > Subversiont.
>
>
> I have to say I'm mildly put off by your repeated suggestions on this
> list to throw away history to make things "easier" during migrations.
> That "compelling need for history" is very likely to be one of the
> reasons for using a version control system in the first place.
>
I do not want to get too deeply involved in this thread, but I will just
say that I do agree with Nico that it should at least be put on the table
for discussion whether the history is really needed. In the corporate
repositories I have seen from customers, more of them seem like complete
rubbish than something to be cherished. The commit messages are often
complete crap if not absent entirely, which means the history is largely
crap as well. You can start off on much better footing by being selective
and migrating the snapshots that you do care about. For example, maybe the
commit messages are crap but you still want the history on your release
boundaries. So you can pretty easily export the snapshots of the various
branches and tags and replay those in your new repository so you can at
least see how code changed across releases. And of course you can often
maintain the old repository as a read only archive to be explored when
needed. If you audit this usage over time you can also pretty easily
decide when it is no longer of value.
Anyway, Nico did not say make a blanket statement to not migrate history.
He said "Unless you have a compelling need for history". One obvious
compelling need is if you have good and useful history like we have in the
Subversion project. If that is the case, then I would be in favor of going
the extra mile to preserve it as well. I think anyone would.
But what I see from a lot of people is something like "We want to move from
VSS to SVN. How do we migrate our repository?" It is a valid question to
make sure they have considered how important it is to migrate all history.
I think that is just the default position everyone starts with because if
migrating the history is easy then it is one less decision to have to make.
In the little experience I have with VSS to SVN migrations, which is
largely second hand in providing support for the SVN part, the actual
migration is not terribly difficult. Meaning the tools that exist
generally seem to work properly. The issue is that a lot of VSS
repositories have hidden corruptions that do not surface until you try to
migrate the history. It seems like the corruptions are often in the
history or something, so it is only when you start trying to extract old
data that it surfaces. This is what has historically complicated these VSS
migrations and why some users say it is easy and others have a lot of
trouble. When you have these corruptions the extractions fail and the
migrators cannot run unless you manually fix the corruption.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Which is the best tool /process to migrate VSS (with history) to
Subversion
Posted by Branko Čibej <br...@apache.org>.
On 26.06.2016 05:48, Nico Kadel-Garcia wrote:
>>> This is borne out by the software difficulty,
>>> and apparent nwillingness by developers to pursue or support the
>>> long-requested "obliterate" feature. Despite it being one of the most
>>> requested feature changes, it's never worked, nor do the updated
>>> versions of Subversion seem to even support leaving room to implement
>>> it.
>> Wow, where did that come from? It has nothing to do with the OP's
>> question, for sure, since he was asking how to migrate from VSS to
>> Subversion.
> It addresses the general "we are put off by how frequently you suggest
> discarding history in a migraiton" comment.
It was not general and it was not "we". I said *I* am mildly put off by
your repeated off-topic suggestions to ditch version control history.
As for that "apparent unwillingness" \u2014 I invite you to read the dev@
mailing list archives from about 4 years ago, specifically the bit about
obliterate and Julian's attempt to specify and implement it. That was
just the latest attempt, and by no means the only one.
Next time, do your homework before scattering insults around like that.
-- Brane
Re: Which is the best tool /process to migrate VSS (with history) to Subversion
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sun, Jun 26, 2016 at 10:28 PM, Stefan <lu...@posteo.de> wrote:
> On 6/26/2016 05:48, Nico Kadel-Garcia wrote:
>> On Sat, Jun 25, 2016 at 8:24 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>>>> Last: one of the most pernicious sources of bugs in Subversion's
>>>> history, one that I've encountered personally, has been the upgrade
>>>> process between releases of Subversion for the repository itself If
>>>> you don't need to have the dataqbase and fileysstem baggage of a full
>>>> history, then the bugs of upgrading become much more avoidable.
>>> Can you be more specific? What bug has broken your repository during
>>> upgrade? Were you careful enough yourself, as an administrator, while
>>> performing such a critical operation to the "crown jewels" of some
>>> developer team?
>> This one.
>>
>> http://stackoverflow.com/questions/10279222/how-can-i-fix-the-svn-import-line-endings-error
> I remember the old discussions relating to this issue only very faintly,
> but the same thread suggests the issue was "resolved" in SVN 1.7 and if
> I'm not mistaken this was done by adding the --bypass-prop-validation
> command line option to svnadmin load.
Agreed, that was an annoying problem (caused by adding the "no longer
accepts CR's in svn:* property values", without offering a way to
repair it or ignore it while loading a dumpfile).
It's not a data corruption bug though, which was what it sounded like
to me. It sounded like Nico ran into an upgrade bug that caused
irreparable corruption to the upgraded repository. The worst that can
happen is that you cannot dump+load your old repository into the new
format.
Anyway, point taken, that bug was / is an annoying problem.
--
Johan
Re: Which is the best tool /process to migrate VSS (with history) to
Subversion
Posted by Stefan <lu...@posteo.de>.
On 6/27/2016 03:33, Daniel Shahaf wrote:
> Stefan wrote on Sun, Jun 26, 2016 at 22:28:20 +0200:
>> On 6/26/2016 05:48, Nico Kadel-Garcia wrote:
>>> http://stackoverflow.com/questions/10279222/how-can-i-fix-the-svn-import-line-endings-error
>> I remember the old discussions relating to this issue only very faintly,
>> but the same thread suggests the issue was "resolved" in SVN 1.7 and if
>> I'm not mistaken this was done by adding the --bypass-prop-validation
>> command line option to svnadmin load.
>>
>> I've been around for quite some time in SVN and did a lot of repository
>> upgrades myself and while there were certainly issues with the upgrade
>> process due to some specific edge cases, side effects of other problems,
>> or even issues in the upgrade code, issues during an upgrade process are
>> really everything else but common. So while that particular problem it
>> wasn't resolved on the 1.6 branch, it got resolved on 1.7.x+.
>>
>> One might question the way version releases go in SVN and the lack of a
>> more stable long term ESR release, but at some point you have to just
>> make a call based on available resources. There's only a limited amount
>> of manpower available and you have to decide what to focus on.
> The reason --bypass-prop-validation wasn't backported to 1.6.x has
> nothing to do with manpower. Adding a --option flag is an API change so
> may not be done in a patch release, only in a minor release.
>
> Ideally we would have discovered the problem during the 1.6.0
> alpha/beta/rc phase, then we could have added the option flag before the
> 1.6.0 release.
I should have made it stand out more clearly that I didn't suggest that
this particular case was related to the statement of limited manpower.
The statement about limited resources is merely my personal conclusion
why only the current version receives bugfixes and why there's only one
previous old stable version which receives security/data corruption
fixes (I haven't heard that statement directly from any SVN developer,
but I always took it for the being the logical reason --- I might stand
corrected though).
>
>> SVN is a really stable product, even with (or actually maybe because of)
>> the policy of only supporting the current and the previous release (and
>> for the previous release only backport security and data corruption fixes).
>> While the downside of this is that in some cases bugs won't be resolved
>> in previous releases anymore, it also helps to improve the stability of
>> the old-stable versions (since only absolutely vital code changes get in
>> and therefore you reduce the risk of adding new issues).
> I always thought the "only security and data corruption" rule was
> a lower bound but not an upper bound; that is: other bugfixes are also
> eligible to be nominated and backported, even if in practice few
> non-critical bugfixes garner three +1 votes in the older minor line's
> STATUS file.
Well, if it is like this, then I might have gotten a false impression.
That said, thanks for the clarification of how you understand the
statement. I'll certainly take that into account and might propose
bugfixes for non-security/-data-loss issues in the future, if I feel
strongly enough about them.
Rergards,
Stefan
Re: Which is the best tool /process to migrate VSS (with history) to
Subversion
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan wrote on Sun, Jun 26, 2016 at 22:28:20 +0200:
> On 6/26/2016 05:48, Nico Kadel-Garcia wrote:
> > http://stackoverflow.com/questions/10279222/how-can-i-fix-the-svn-import-line-endings-error
> I remember the old discussions relating to this issue only very faintly,
> but the same thread suggests the issue was "resolved" in SVN 1.7 and if
> I'm not mistaken this was done by adding the --bypass-prop-validation
> command line option to svnadmin load.
>
> I've been around for quite some time in SVN and did a lot of repository
> upgrades myself and while there were certainly issues with the upgrade
> process due to some specific edge cases, side effects of other problems,
> or even issues in the upgrade code, issues during an upgrade process are
> really everything else but common. So while that particular problem it
> wasn't resolved on the 1.6 branch, it got resolved on 1.7.x+.
>
> One might question the way version releases go in SVN and the lack of a
> more stable long term ESR release, but at some point you have to just
> make a call based on available resources. There's only a limited amount
> of manpower available and you have to decide what to focus on.
The reason --bypass-prop-validation wasn't backported to 1.6.x has
nothing to do with manpower. Adding a --option flag is an API change so
may not be done in a patch release, only in a minor release.
Ideally we would have discovered the problem during the 1.6.0
alpha/beta/rc phase, then we could have added the option flag before the
1.6.0 release.
> SVN is a really stable product, even with (or actually maybe because of)
> the policy of only supporting the current and the previous release (and
> for the previous release only backport security and data corruption fixes).
> While the downside of this is that in some cases bugs won't be resolved
> in previous releases anymore, it also helps to improve the stability of
> the old-stable versions (since only absolutely vital code changes get in
> and therefore you reduce the risk of adding new issues).
I always thought the "only security and data corruption" rule was
a lower bound but not an upper bound; that is: other bugfixes are also
eligible to be nominated and backported, even if in practice few
non-critical bugfixes garner three +1 votes in the older minor line's
STATUS file.
Cheers,
Daniel
Re: Which is the best tool /process to migrate VSS (with history) to
Subversion
Posted by Stefan <lu...@posteo.de>.
On 6/26/2016 05:48, Nico Kadel-Garcia wrote:
> On Sat, Jun 25, 2016 at 8:24 PM, Johan Corveleyn <jc...@gmail.com> wrote:
>>> Last: one of the most pernicious sources of bugs in Subversion's
>>> history, one that I've encountered personally, has been the upgrade
>>> process between releases of Subversion for the repository itself If
>>> you don't need to have the dataqbase and fileysstem baggage of a full
>>> history, then the bugs of upgrading become much more avoidable.
>> Can you be more specific? What bug has broken your repository during
>> upgrade? Were you careful enough yourself, as an administrator, while
>> performing such a critical operation to the "crown jewels" of some
>> developer team?
> This one.
>
> http://stackoverflow.com/questions/10279222/how-can-i-fix-the-svn-import-line-endings-error
I remember the old discussions relating to this issue only very faintly,
but the same thread suggests the issue was "resolved" in SVN 1.7 and if
I'm not mistaken this was done by adding the --bypass-prop-validation
command line option to svnadmin load.
I've been around for quite some time in SVN and did a lot of repository
upgrades myself and while there were certainly issues with the upgrade
process due to some specific edge cases, side effects of other problems,
or even issues in the upgrade code, issues during an upgrade process are
really everything else but common. So while that particular problem it
wasn't resolved on the 1.6 branch, it got resolved on 1.7.x+.
One might question the way version releases go in SVN and the lack of a
more stable long term ESR release, but at some point you have to just
make a call based on available resources. There's only a limited amount
of manpower available and you have to decide what to focus on.
SVN is a really stable product, even with (or actually maybe because of)
the policy of only supporting the current and the previous release (and
for the previous release only backport security and data corruption fixes).
While the downside of this is that in some cases bugs won't be resolved
in previous releases anymore, it also helps to improve the stability of
the old-stable versions (since only absolutely vital code changes get in
and therefore you reduce the risk of adding new issues).
Regards,
Stefan
Re: Which is the best tool /process to migrate VSS (with history) to Subversion
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Jun 25, 2016 at 8:24 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> Of course if your developers have not cared much for history, so that
> it's already mostly worthless, maybe it's not a big deal to ditch it.
> But I wouldn't like to work in such an environment. Most developers I
> know care about a good commit history with adequate log messages, so
> there is enough metadata with the code to help keep it maintainable.
History is most valuable when it's done well, and it can be useful. A
great deal of history can be confusing and problematic: it's
especially ripe for confusion when migrating source control systems.
>> But there are quite a few procedural and support reasons to make a
>> clean break when doing a migration. Migrations, with changes to a new
>> upstream repository URL and clients expected to switch to new
>> repositories, are just about the only safe time you can clear
>> accumulated debris in Subversion repositories. This is due to a number
>> of procedural practices, namely the long-standing implicit policy that
>> history is immutable. This is borne out by the software difficulty,
>> and apparent nwillingness by developers to pursue or support the
>> long-requested "obliterate" feature. Despite it being one of the most
>> requested feature changes, it's never worked, nor do the updated
>> versions of Subversion seem to even support leaving room to implement
>> it.
>
> Wow, where did that come from? It has nothing to do with the OP's
> question, for sure, since he was asking how to migrate from VSS to
> Subversion.
It addresses the general "we are put off by how frequently you suggest
discarding history in a migraiton" comment.
> I'm a really easy going guy, but a statement blaming the "apparent
> unwillingness by developers" really pisses me off. There have been
> several serious efforts, and lots and lots of brainstorming and
> discussion trying to come up with a good design for "obliterate". Your
> statement is frankly insulting to those people who have invested their
> time and effort into this.
It's been 15 years. There is not a single line of code apparent in any
development branch supporting the feature. The svnadmin
dump/filter/load procedures remain the only way to do it, and they
sitll don't work well for content that has been re-arranged.
> I can understand you're frustrated that this hasn't been implemented
> even after all these years. But the simple fact is that this is very
> difficult to do within SVN's architecture, while maintaining backwards
> compatibility and interaction with all existing behaviour
> ("obliterate" was unfortunately not a part of svn's initial
> architecture / design; we cannot go back in time to change that). And
> there have been other very important features that needed work.
Which seems to translate to "unwillingness".
> Apart from that I can only say: this is an open source project. Feel
> free to drive an effort yourself (starting with discussing a
> functional specification and/or a design on the dev@ list -- after
> first studying some of the previous discussions and efforts to avoid
> repeating old arguments). And if you'd still feel the other devs are
> unwilling and blocking your great ideas, you can always create your
> own fork of svn, ignore backwards compatibility and all the
> interactions with other features that you don't care about, and do
> whatever you want.
I just raised one of the simplest working solution to the problem. Use
an export/import rather than attempting to preserve all history. There
are certainly features you lose: as you mention, the history and
ability to use "svn blame" to track changes is one of them.
>> Last: one of the most pernicious sources of bugs in Subversion's
>> history, one that I've encountered personally, has been the upgrade
>> process between releases of Subversion for the repository itself If
>> you don't need to have the dataqbase and fileysstem baggage of a full
>> history, then the bugs of upgrading become much more avoidable.
>
> Can you be more specific? What bug has broken your repository during
> upgrade? Were you careful enough yourself, as an administrator, while
> performing such a critical operation to the "crown jewels" of some
> developer team?
This one.
http://stackoverflow.com/questions/10279222/how-can-i-fix-the-svn-import-line-endings-error
> Of course, no software is without bugs. But the SVN developers try
> very hard to make the code (especially the back-end code) as robust as
> possible. You make it sound like back-end-upgrade bugs are common. I
> think such bugs are very rare.
They're much more rare now. I had problems way back when with various
upgrades and migrations up to about version 1.6. 1.6 had the infamous
"no longer accepts carriage returns in property files" problem with
dumping from ealier versions to load in 1.6: I think that bug is still
there, but I just shot my last Subversion 1.4 client quite recently.
Re: Which is the best tool /process to migrate VSS (with history) to Subversion
Posted by Johan Corveleyn <jc...@gmail.com>.
On Sat, Jun 25, 2016 at 7:20 PM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
> On Wed, Jun 22, 2016 at 12:44 AM, Branko Čibej <br...@apache.org> wrote:
>
>> I have to say I'm mildly put off by your repeated suggestions on this
>> list to throw away history to make things "easier" during migrations.
>> That "compelling need for history" is very likely to be one of the
>> reasons for using a version control system in the first place.
>
> Please excuse the late reply: I've been busy.
>
> Doing a flat export/import is not always considered by an engineer
> asked to do a migration. It's why I mention it. *If* you need it,
> fine. But complete history preservation can turn a 2 hour project of
> locking the old repo, setting up a Subversion server, and doing a flat
> export/import with with svn:ignore, svn:eol, and svn:keywords settings
> set consistently into a 2 month process of repairing broken old
> histories, ensuring identical logs, training users on the
> inconsistencies between their old and new checkouts of the same old
> and obsolete branches, and in general burning cycles better spent on
> necessary tasks like user training and robust backup.
>
> The task of history migraiton is also compounded in complexity if the
> old software repository didn't follow Subversion layout of
> trunk/branches/tags. Been there, done that, with multiple locally
> designed source control systems, with RCS, CVS, git, and once even
> Perforce.
I'm a developer in a large team working on software that has a lot
history. I also have a lot of affinity with sysadmin / svnadmin work
(I know this migration stuff can be challenging, and it usually rests
on the shoulders of one or two people having to do the grunt work).
Everyone can do / suggest what they want, but being an experienced
developer myself, I'm definitely in the camp of "try hard to keep the
history, even if it costs a bit". I know it can be tough on the guy
having to do the actual migration, and maybe require some creativity,
but IMO it's usually worth it. The number of times 'svn blame' or 'svn
log' have helped me to understand a piece of code (sometimes tracing a
change back to some eye-opening commit message from 15 years ago),
saved me countless hours of guesswork ... For me, this is one of the
most valuable things a VCS can provide.
Of course if your developers have not cared much for history, so that
it's already mostly worthless, maybe it's not a big deal to ditch it.
But I wouldn't like to work in such an environment. Most developers I
know care about a good commit history with adequate log messages, so
there is enough metadata with the code to help keep it maintainable.
> I've in fact done both: one dump/load repo with history, locked down
> so that clients have access to the old history with Subversion
> clients, and a file dropped at the top of it with a README.txt saying
> "go use the new repo at this other URL". And the new repo is a flat
> export/import of the finaly release of the software, precisely so it's
> much smaller, much easier to deal with, and it has a README.txt saying
> that the old history and software is available at the other URL.
That makes it so much more difficult for a developer to research
history of a piece of code. If they're in a hurry, they will not do it
and simply take their best guess (and if they guess wrong, they will
blame the lacking version control system which makes it too damn
difficult for them). I'd be -1 on such a procedure, unless it's
really, really the only way.
> But there are quite a few procedural and support reasons to make a
> clean break when doing a migration. Migrations, with changes to a new
> upstream repository URL and clients expected to switch to new
> repositories, are just about the only safe time you can clear
> accumulated debris in Subversion repositories. This is due to a number
> of procedural practices, namely the long-standing implicit policy that
> history is immutable. This is borne out by the software difficulty,
> and apparent nwillingness by developers to pursue or support the
> long-requested "obliterate" feature. Despite it being one of the most
> requested feature changes, it's never worked, nor do the updated
> versions of Subversion seem to even support leaving room to implement
> it.
Wow, where did that come from? It has nothing to do with the OP's
question, for sure, since he was asking how to migrate from VSS to
Subversion.
I'm a really easy going guy, but a statement blaming the "apparent
unwillingness by developers" really pisses me off. There have been
several serious efforts, and lots and lots of brainstorming and
discussion trying to come up with a good design for "obliterate". Your
statement is frankly insulting to those people who have invested their
time and effort into this.
I can understand you're frustrated that this hasn't been implemented
even after all these years. But the simple fact is that this is very
difficult to do within SVN's architecture, while maintaining backwards
compatibility and interaction with all existing behaviour
("obliterate" was unfortunately not a part of svn's initial
architecture / design; we cannot go back in time to change that). And
there have been other very important features that needed work.
Apart from that I can only say: this is an open source project. Feel
free to drive an effort yourself (starting with discussing a
functional specification and/or a design on the dev@ list -- after
first studying some of the previous discussions and efforts to avoid
repeating old arguments). And if you'd still feel the other devs are
unwilling and blocking your great ideas, you can always create your
own fork of svn, ignore backwards compatibility and all the
interactions with other features that you don't care about, and do
whatever you want.
> There are several consequences which I've mentioned before. One is
> that bulky, accidental commits are permanently stored in the
> Subversion repository and cannot be gracefully cleared from history or
> from backups. It's especially a problem for bulky binaries, which can
> easily increase the size of a small source code repository by a factor
> of 1000 if a single CD image is accidentally committed. Been there,
> done that, had to clean up the mess.
>
> Another reason to consider a clean, export/import migration is to
> declare a clean separation between the old, canonical code still
> accessible with the old software clients, and the new repository with
> new default categories of svn:ignore, svn:keywords, svn:eol, and other
> potentially repository wide policies to enforce code consistency.
> Those settings are impossible to backport into the history of a
> repository. New branches generated from old revisions before these
> properties were set will retain the *old* property settings, which may
> be in conflict with newer policy. The results of that, especially of
> failing to use current "svn:ignore" settings, can be the inclusion
> once again of bulky binary files. And the result of mismatched
> "svn:keywords" or "svn:eol" can be surprisingly devastating to
> critical software.
Meh, sounds like a problem that a good developer team should be able
to solve / control by knowing what they are doing. If you introduce
new policies, and there is a chance that you'll still be using
old-policy stuff, you'd better take that into account in your build
scripts or whatever. Or spend some time fixing those old branches that
are still considered resurrectable (not by rewriting history, but
simply by making another commit).
> Last: one of the most pernicious sources of bugs in Subversion's
> history, one that I've encountered personally, has been the upgrade
> process between releases of Subversion for the repository itself If
> you don't need to have the dataqbase and fileysstem baggage of a full
> history, then the bugs of upgrading become much more avoidable.
Can you be more specific? What bug has broken your repository during
upgrade? Were you careful enough yourself, as an administrator, while
performing such a critical operation to the "crown jewels" of some
developer team?
Of course, no software is without bugs. But the SVN developers try
very hard to make the code (especially the back-end code) as robust as
possible. You make it sound like back-end-upgrade bugs are common. I
think such bugs are very rare.
--
Johan
Re: Which is the best tool /process to migrate VSS (with history) to Subversion
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Wed, Jun 22, 2016 at 12:44 AM, Branko Čibej <br...@apache.org> wrote:
> I have to say I'm mildly put off by your repeated suggestions on this
> list to throw away history to make things "easier" during migrations.
> That "compelling need for history" is very likely to be one of the
> reasons for using a version control system in the first place.
Please excuse the late reply: I've been busy.
Doing a flat export/import is not always considered by an engineer
asked to do a migration. It's why I mention it. *If* you need it,
fine. But complete history preservation can turn a 2 hour project of
locking the old repo, setting up a Subversion server, and doing a flat
export/import with with svn:ignore, svn:eol, and svn:keywords settings
set consistently into a 2 month process of repairing broken old
histories, ensuring identical logs, training users on the
inconsistencies between their old and new checkouts of the same old
and obsolete branches, and in general burning cycles better spent on
necessary tasks like user training and robust backup.
The task of history migraiton is also compounded in complexity if the
old software repository didn't follow Subversion layout of
trunk/branches/tags. Been there, done that, with multiple locally
designed source control systems, with RCS, CVS, git, and once even
Perforce.
I've in fact done both: one dump/load repo with history, locked down
so that clients have access to the old history with Subversion
clients, and a file dropped at the top of it with a README.txt saying
"go use the new repo at this other URL". And the new repo is a flat
export/import of the finaly release of the software, precisely so it's
much smaller, much easier to deal with, and it has a README.txt saying
that the old history and software is available at the other URL.
But there are quite a few procedural and support reasons to make a
clean break when doing a migration. Migrations, with changes to a new
upstream repository URL and clients expected to switch to new
repositories, are just about the only safe time you can clear
accumulated debris in Subversion repositories. This is due to a number
of procedural practices, namely the long-standing implicit policy that
history is immutable. This is borne out by the software difficulty,
and apparent nwillingness by developers to pursue or support the
long-requested "obliterate" feature. Despite it being one of the most
requested feature changes, it's never worked, nor do the updated
versions of Subversion seem to even support leaving room to implement
it.
There are several consequences which I've mentioned before. One is
that bulky, accidental commits are permanently stored in the
Subversion repository and cannot be gracefully cleared from history or
from backups. It's especially a problem for bulky binaries, which can
easily increase the size of a small source code repository by a factor
of 1000 if a single CD image is accidentally committed. Been there,
done that, had to clean up the mess.
Another reason to consider a clean, export/import migration is to
declare a clean separation between the old, canonical code still
accessible with the old software clients, and the new repository with
new default categories of svn:ignore, svn:keywords, svn:eol, and other
potentially repository wide policies to enforce code consistency.
Those settings are impossible to backport into the history of a
repository. New branches generated from old revisions before these
properties were set will retain the *old* property settings, which may
be in conflict with newer policy. The results of that, especially of
failing to use current "svn:ignore" settings, can be the inclusion
once again of bulky binary files. And the result of mismatched
"svn:keywords" or "svn:eol" can be surprisingly devastating to
critical software.
Last: one of the most pernicious sources of bugs in Subversion's
history, one that I've encountered personally, has been the upgrade
process between releases of Subversion for the repository itself If
you don't need to have the dataqbase and fileysstem baggage of a full
history, then the bugs of upgrading become much more avoidable.
Re: Which is the best tool /process to migrate VSS (with history) to
Subversion
Posted by Branko Čibej <br...@apache.org>.
On 20.06.2016 15:04, Nico Kadel-Garcia wrote:
> On Mon, Jun 20, 2016 at 8:45 AM, Stefan Hett <st...@egosoft.com> wrote:
>> On 6/20/2016 1:07 PM, Yerra Babji wrote:
>>> Hi,
>>>
>>> I am looking for best tool / process to migrate VSS folders (with history
>>> ) to Subversion.
>>>
>>> Thanks in advance for your suggestions.
>> 7 years ago when I migrated VSS to SVN in our company, I used this tool:
>> http://vssmigrate.codeplex.com/
>> Had some issues, but it turned out to do the job quite well (check out the
>> reported issues there - think I reported everything I ran into back then
>> which wasn't reported already).
>>
>> 7 years is quite a while ago. So maybe nowadays there are better solutions
>> available. Just google and see if you find a more mature product out there.
>> vss2svn seems to be suggested quite often and there also seems to be an
>> commercial importer available from Polarion.
> Unless you have a compelling need for history, I'd suggest you do a
> simple export o a working copy from VSS to a simple export in
> Subversiont.
I have to say I'm mildly put off by your repeated suggestions on this
list to throw away history to make things "easier" during migrations.
That "compelling need for history" is very likely to be one of the
reasons for using a version control system in the first place.
-- Brane
Re: Which is the best tool /process to migrate VSS (with history)
to Subversion
Posted by pjaytycy <pi...@gmail.com>.
> Unless you have a compelling need for history, I'd suggest you do a
> simple export o a working copy from VSS to a simple export in
> Subversiont.
>
I would argue to keep the history. It's very frustrating if 50+% of the
times you use blame (to hopefully get some reasoning / context for a
particular code section), you end up with the absolutely useless "initial
import from <previous VCS>" .
Re: Which is the best tool /process to migrate VSS (with history) to
Subversion
Posted by Stefan <lu...@posteo.de>.
On 6/20/2016 15:04, Nico Kadel-Garcia wrote:
> On Mon, Jun 20, 2016 at 8:45 AM, Stefan Hett <st...@egosoft.com> wrote:
>> On 6/20/2016 1:07 PM, Yerra Babji wrote:
>>> Hi,
>>>
>>> I am looking for best tool / process to migrate VSS folders (with history
>>> ) to Subversion.
>>>
>>> Thanks in advance for your suggestions.
>> 7 years ago when I migrated VSS to SVN in our company, I used this tool:
>> http://vssmigrate.codeplex.com/
>> Had some issues, but it turned out to do the job quite well (check out the
>> reported issues there - think I reported everything I ran into back then
>> which wasn't reported already).
>>
>> 7 years is quite a while ago. So maybe nowadays there are better solutions
>> available. Just google and see if you find a more mature product out there.
>> vss2svn seems to be suggested quite often and there also seems to be an
>> commercial importer available from Polarion.
> Unless you have a compelling need for history, I'd suggest you do a
> simple export o a working copy from VSS to a simple export in
> Subversiont. That provides an opportunity to prune bulky and undesired
> content and history, and avoid anyone thining that the Subversion is
> an exact replica of VSS. It really isn't, anymore than a CD is an
> exact replica of a phonograph, and it provides an opportunity to avoid
> developers used to one thinking that their workflow and tools will map
> exactly to the other.
>
> This is especially helpful when migrating different projects *from*
> Subversion, because of the longstanding lack of any "obliterate"
> command in Subversion to clear bulky, accidental commits or security
> sensitive commits. The result is often a tendency to accumulate
> clutter, clutter that is very awkward if not impossible to clear even
> by filtering svnadmin dump and load operations.
IMO this advice is highly depending on the exact circumstances/case. In
general I would not suggest to drop the history. At least when we are
talking source-code repositories. You are just losing a lot of
information you would require in the general case.
If the information a CVS provides you with is not worth of keeping in a
case, I would highly question using a CVS at all for this particular
scenario, since that would suggest that you just as well could live with
a simple shared drive with synchronization capabilities and don't need a
CVS at all.
So in general for someone who wants to migrate a CVS to a different one,
I would assume that the history is a vital part of the data and not
something which could/should be pruned.
If there are things which bloat an old CVS which you don't want for
whatever reason not to take over to the new SVN repository, using
dumpfilters might be the way to go in order to filter out specific data
(like large files, data before a certain timestamp, binary files, etc.).
Also with the available tools nowadays, it's not that difficult IMHO to
migrate VSS to SVN sustaining the majority (if not all) of the previous
VSS data. In my case the work was (as far as I remember) around 1-2 man
weeks for a 10 year old source code VSS repository. And that was me
doing that the first time without any previous knowledge about VSS
migration and only average knowledge on SVN. For an experienced person
it's normally a matter of a day or two to perform the migration (talking
here worktime, not process time which certainly will be more than that).
Regards,
Stefan
Re: Which is the best tool /process to migrate VSS (with history) to Subversion
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Mon, Jun 20, 2016 at 8:45 AM, Stefan Hett <st...@egosoft.com> wrote:
> On 6/20/2016 1:07 PM, Yerra Babji wrote:
>>
>> Hi,
>>
>> I am looking for best tool / process to migrate VSS folders (with history
>> ) to Subversion.
>>
>> Thanks in advance for your suggestions.
>
> 7 years ago when I migrated VSS to SVN in our company, I used this tool:
> http://vssmigrate.codeplex.com/
> Had some issues, but it turned out to do the job quite well (check out the
> reported issues there - think I reported everything I ran into back then
> which wasn't reported already).
>
> 7 years is quite a while ago. So maybe nowadays there are better solutions
> available. Just google and see if you find a more mature product out there.
> vss2svn seems to be suggested quite often and there also seems to be an
> commercial importer available from Polarion.
Unless you have a compelling need for history, I'd suggest you do a
simple export o a working copy from VSS to a simple export in
Subversiont. That provides an opportunity to prune bulky and undesired
content and history, and avoid anyone thining that the Subversion is
an exact replica of VSS. It really isn't, anymore than a CD is an
exact replica of a phonograph, and it provides an opportunity to avoid
developers used to one thinking that their workflow and tools will map
exactly to the other.
This is especially helpful when migrating different projects *from*
Subversion, because of the longstanding lack of any "obliterate"
command in Subversion to clear bulky, accidental commits or security
sensitive commits. The result is often a tendency to accumulate
clutter, clutter that is very awkward if not impossible to clear even
by filtering svnadmin dump and load operations.
Re: Which is the best tool /process to migrate VSS (with history) to
Subversion
Posted by Stefan Hett <st...@egosoft.com>.
On 6/20/2016 1:07 PM, Yerra Babji wrote:
> Hi,
>
> I am looking for best tool / process to migrate VSS folders (with
> history ) to Subversion.
>
> Thanks in advance for your suggestions.
7 years ago when I migrated VSS to SVN in our company, I used this tool:
http://vssmigrate.codeplex.com/
Had some issues, but it turned out to do the job quite well (check out
the reported issues there - think I reported everything I ran into back
then which wasn't reported already).
7 years is quite a while ago. So maybe nowadays there are better
solutions available. Just google and see if you find a more mature
product out there. vss2svn seems to be suggested quite often and there
also seems to be an commercial importer available from Polarion.
--
Regards,
Stefan Hett