[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Thoughts and open questions on patch/dump unification

From: Dave Rolsky <autarch_at_urth.org>
Date: 2004-09-17 01:47:25 CEST

On Fri, 17 Sep 2004, Max Bowsher wrote:

> > Storing merge history will be in the subversion core in the future,
> > according to the project's todo list. But the developers have been pretty
> > clear that decentralized version control is not one of the their main
> > goals.
>
> Correct - but "not a main goal" is not the same as "go away, we don't want
> it even if well designed and coded". I'm only 1 opinion, but I don't see any
> reason why certain core svk-alike features couldn't migrate into subversion
> itself eventually.

Agreed on the first point. On the second, the only problem there is that
SVK is moving at an incredibly fast pace. Porting its feature set to
Subversion would require catching up with it and writing all that code in
C. C is not known for its quick development speed ;)

But I'd imagine that if someone did the work, the core developers would
take a serious look at incorporating it. I just don't know that
convincing them to do it themselves is possible.

On the subject of a more comprehensive patch format that applies to trees,
that certainly seems like a useful thing.

> Although (IMO) it's easier to write unmaintainable code in Perl, it's
> possible to write Perl which is just as maintainable as Python, given a bit
> of discipline.

I suspect it's also possible to write Python which is just as
unmaintainable as Perl, given a lack of discipline ;)

-dave

/*===========================
VegGuide.Org
Your guide to all that's veg.
===========================*/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 17 01:47:39 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.