Hm, I had what might be a good idea.  See this "best practices" doc  
which suggests that you maintain a darcs-1-format repository for your  
darcs-1-executable-using users, and that you also create a hashed- 
format repository for your darcs-2-executable-using users, and that  
you set up scripts to sync the two of them?

http://wiki.darcs.net/DarcsWiki/ 
DarcsTwo#head-98abd90796d98fd11798ca867157815e6fb4d1f3

Well, it occurs to me that this practice might be completely  
automatable -- darcs might be able to automatically maintain a  
darcs-1-compatible repository in parallel with the hashed-format  
repository, and to make them both available under the same path/URL.

If so, this would probably help people upgrade gracefully.

Regards,

Zooko
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $5/month

Automatic compatibility between hashed and old format repositories would be nice
to have, but I fear this would be too invasive a change for us.

What do you think, Jason?

Zooko: is there anything we can do that might ease the upgrade path?  I hope
that we can get far enough just by encouraging people to use hashed repositories
locally and gently encouraging server admins to upgrade their darcs binaries.

On Aug 29, 2008, at 1:22 AM, Eric Kow wrote:

> Zooko: is there anything we can do that might ease the upgrade  
> path?  I hope
> that we can get far enough just by encouraging people to use hashed  
> repositories
> locally and gently encouraging server admins to upgrade their darcs  
> binaries.

Fresher darcs-2 binaries for more platforms [1].  The traditional way  
to do this is to ask volunteers to do it, but I think it would be  
better to ask the volunteers to contribute a buildslave and to help  
write the buildslave script for building and uploading binaries.

Other than that -- and the topic of this ticket -- I can't think of  
anything.  Darcs-2 is already propagating through the Free Software  
ecosystem, e.g. Debian Lenny [2].  The general strategy that David  
Roundy launched with darcs-2 and the three repository formats is a  
good strategy for graceful upgrade.  (Although it continues to be a  
problem that people confuse darcs-1-executables with darcs-1- 
repository-format and darcs-2-executables with darcs-2-repository- 
format, but it's too late to do anything about that now.  Or is it?   
Hm...)

It would help to fix any regressions and release darcs-2.0.3 ASAP,  
and for the 2.0.3 release announcement to be written and sent by  
someone other than David Roundy.  I don't mean any slight to David  
Roundy, for whom I have great respect and appreciation, but he has  
demonstated, and stated, that he is not the right person for that job.

That's all I can think of.

Regards,

Zooko

[1] http://wiki.darcs.net/DarcsWiki/CategoryBinaries
[2] http://packages.debian.org/lenny/darcs
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $5/month

Indeed http://bugs.darcs.net/issue997 would be a great feature (especially for
our poor Windows users).  Marking wont-fix and thinking about 2.0.3.
Thanks!

So for the record, why is it that you won't make darcs maintain a darcs-1-format
repository internally?  Because it would complicate the darcs source?  In this
ticket kowey asked Jason for his opinion on that, but Jason didn't reply.

I thought it would complicate the darcs source, that the resulting
combo-repositories might confuse older darcs >= 2.0.0, and that the feature
(interesting as it is) wouldn't be used enough to justify the extra work all the
more because there already is a workaround, and finally that by the time we did
implement a feature like this, darcs 2 would be in much wider circulation anyway
and therefore it would be moot.

I am willing to be corrected, of course

Those sound like good reasons to me.  I guess I was hoping that it would turn
out to be easy.

On Sat, Aug 30, 2008 at 6:10 AM, Zooko <bugs@darcs.net> wrote:
>
> Zooko <zooko@zooko.com> added the comment:
>
> So for the record, why is it that you won't make darcs maintain a darcs-1-format
> repository internally?  Because it would complicate the darcs source?  In this
> ticket kowey asked Jason for his opinion on that, but Jason didn't reply.

Indeed.  Sorry about not replying.  My opinion:

Because darcs-1 and darcs-2 repositories vary mostly by semantics and
only slightly by file format, I guess I don't really know how to make
darcs-2 semantics map into darcs-1 semantics without all the familiar
problems of darcs-1 repositories.  I'm concerned that the darcs-1
pristine would diverge from the darcs-2 pristine.  Then what would be
the meaning of a given set of patches in a particular branch?

It sounds like a nice usability feature, but I can't really see how to
make it feasible in practice.

I hope that helps,
Jason

On Sun, 31 Aug 2008, Jason Dagit wrote:

> Because darcs-1 and darcs-2 repositories vary mostly by semantics and
> only slightly by file format, I guess I don't really know how to make
> darcs-2 semantics map into darcs-1 semantics without all the familiar
> problems of darcs-1 repositories.  I'm concerned that the darcs-1
> pristine would diverge from the darcs-2 pristine.  Then what would be
> the meaning of a given set of patches in a particular branch?

I thought the suggestion was for compatibility between darcs 1 repos and 
hashed repositories that were still using darcs 1 semantics, rather than 
full-blown darcs-2 repos.

Cheers,

Ganesh

On Aug 31, 2008, at 11:33 AM, Ganesh Sittampalam wrote:
>
> I thought the suggestion was for compatibility between darcs 1  
> repos and
> hashed repositories that were still using darcs 1 semantics, rather  
> than
> full-blown darcs-2 repos.

Yes, my idea was to automate this "best practice":

http://wiki.darcs.net/DarcsWiki/DarcsTwo#head- 
ca2e53d78a98ca8e9a613d9021e7563e6476b943

Which means maintain an old-fashioned-format repository and a hashed- 
format repository in sync with one another.

I know I could do all of this with a shell script (and in fact I  
have), except for the part about there being a single URL which acts  
as an old-fashioned-format repository when a darcs-1-executable tries  
to push or pull and acts as a hashed-format repository when a darcs-2- 
executable tries to push or pull.  The current implementation that I  
have requires you to specify which kind of repository you want to  
talk to by the URL (in the example code on the wiki I append "- 
hashedformat" to the hashed-format repository).

So I'm sure that at least part of this is implementable, since it is  
already done by a combination of shell scripts and post-apply  
hooks.  :-)

It occurs to me that even if this could be implemented easily enough  
in Haskell and the two URLs could be unified into one, it would still  
cause a performance reduction, so that's another reason not to do it.

Regards,

Zooko
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $5/month