[darcs-users] old-fashioned repository support in darcs 2.8

Eric Kow kowey at darcs.net
Wed Nov 17 15:26:45 UTC 2010


On Tue, Nov 16, 2010 at 00:48:29 +0100, Guillaume Hoffmann wrote:
> Possible options for OF support in 2.8 are:

Keeping in mind that we already agree in principle that we should
try remove old-fashioned support.

The question is if it's practical to aim for it in 2.8.

If we don't reach any sort of consensus, I offer to commit to removing
OF support by Darcs 2.8 if you are willing to do the job of adequately
preparing users for what's ahead. I think this means getting the
communications under control (darcs users may not read darcs-users or
any darcs mediums) and also  making sure that Darcs 2.5.1 does the right
things.

>     1) Keeping full OF support
>     2) Keeping all read-only support
>     3) Keeping only darcs optimize --upgrade support

We didn't do enough to prepare darcs users (who don't all read the
mailing list) for withdrawing old-fashioned.

If we want to remove old-fashioned support in 2.8, we should probably
release a darcs 2.5.1 which works harder at preparing users for what's
ahead.

> My proposal on how we hack our way towards this objective is to make a
> series of easily reviewable patches, that remove features associated
> to OF repositories one after another. The following commands can be
> successively removed: optimize --relink-pristine, get --old, put
> --old, init --old, and then (one by one) all commands that write into
> repositories. Whatsnew and diff should be deprecated for OF also:
> although they are read-only, they require a pristine.

Easily reviewable self-contained chunks are indeed more likely to land
in HEAD.

> Lastly, I do not think we should commit to the contract "if, by 2.8,
> hashed repos are not as fast as OF repos we should put back full OF
> support in the code".

I don't think anybody was suggesting that :-)

If it helps, I think that we should shift our general emphasis from
performance to code quality.  This includes being willing to make
cleanups that introduce performance regressions and letting certain
performance regressions stay regressed.  It's a different story if we
introduce something catastrophic.

I have a rough outline in my head that goes like this:

- short term  : performance
- medium term : code quality
- long term   : darcs 3

I think we're in the transition between short/medium term.  We still
have fast get over networks and faster annotate lined up, but after
that, darcs library all the way?

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
For a faster response, try +44 (0)1273 64 2905 or
xmpp:kowey at jabber.fr (Jabber or Google Talk only)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20101117/aedb477a/attachment.pgp>


More information about the darcs-users mailing list