On Sat, Jun 25, 2016 at 7:20 PM, Nico Kadel-Garcia <nkadel_at_gmail.com> wrote:
> On Wed, Jun 22, 2016 at 12:44 AM, Branko Čibej <brane_at_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
Received on 2016-06-26 02:25:23 CEST