On Sat, Jun 25, 2016 at 8:24 PM, Johan Corveleyn <jcorvel_at_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.
Received on 2016-06-26 05:48:46 CEST