This is confusing:

    $ darcs anno .Xdefaults

    darcs failed:  There is no file or directory named '.Xdefaults'

because .Xdefaults is clearly managed by darcs:

    $ darcs w -s .Xdefaults
    What's new in ".Xdefaults":

    M ./.Xdefaults -1 +1

I presume the problem is really that I'm using a partially-gotten repo:

    $ darcs cha .Xdefaults
    Changes to .Xdefaults:

    Mon May 21 22:31:23 EST 2007  Trent Buck <>
      * .Xdefaults: more consistent fonts.
    Can't find changes prior to:
    Sun May 20 00:18:08 EST 2007  Trent Buck <trentbuck@gmail.com>
      * .emacs-prefs/rcirc.el: nonstupid log dir.

It would be nice if darcs annotate gave a less obtuse error.
-- 
Trent Buck

I agree with Trent that this error could be improved. However, my inclination is
to consider this "resolved in unstable", by recommending using lazy repos over
partial ones, since partial ones seemed to have fundamentally not worked as well
as well hoped as a design. 

In other words, the solution seems to be avoiding using partial repos, not
fixing the problems with them.

I agree with Mark on this.  We're giving up --partial repositories.  And for
--lazy repositories this message is exactly accurate:  the source has
disappeared, and we can't find those changes.

Would it be reasonable to remove --partial from the user interface (or perhaps
alias it to --lazy)?

On Feb 1, 2008 10:45 AM, Eric Kow <bugs@darcs.net> wrote:
> Would it be reasonable to remove --partial from the user interface (or perhaps
> alias it to --lazy)?

I'm hesitant to do this, because --partial isn't the same thing as
--lazy.  And because I don't think we want to drop support for partial
repositories for users of old-fashioned repositories.  Although it
would simplify our code to do so.

David

> I'm hesitant to do this, because --partial isn't the same thing as
> --lazy.  And because I don't think we want to drop support for partial
> repositories for users of old-fashioned repositories.  Although it
> would simplify our code to do so.

Hmm, well I wasn't hoping for a code simplification, because I was
thinking of removing just the flag and leaving the actual back-end
code in (because some people still have partial repositories on which
darcs ought to keep
working).  The disadvantage is that it would force people to do a slow
complete get on
old repositories (maybe that's a good thing; encourage more use of
hashed inventory, hehe), but the advantage is that they no longer run
into any --partial induced bug.

Or maybe we could just add to the documentation that partial
repositories should ideally be used only if you are only planning
to get or pull, and not if you want to record/push/etc.

As a third option, darcs could explicitly keep track of whether the
repository is in partial mode or not (which should be easy?), and
either outright refuse to do certain tricky
operations, or emit a warning to the effect of "This might break!"

My opinion is to immediately document in the short and long documentation that
--partial is a legacy support option, and not recommended. The long docs can
mention that "it may be removed at some future date". 

I light of other possibility priorities, I don't like the idea of spending more
time to code around the broken-ness of --partial, when we have a working
alternative that is easy to switch to. 

The essential thing seems to be communicate clearly the state of things.

On Fri, Feb 01, 2008 at 05:34:19PM -0000, Eric Kow wrote:
> > I'm hesitant to do this, because --partial isn't the same thing as
> > --lazy.  And because I don't think we want to drop support for partial
> > repositories for users of old-fashioned repositories.  Although it
> > would simplify our code to do so.
> 
> Hmm, well I wasn't hoping for a code simplification, because I was
> thinking of removing just the flag and leaving the actual back-end code
> in (because some people still have partial repositories on which darcs
> ought to keep working).  The disadvantage is that it would force people
> to do a slow complete get on old repositories (maybe that's a good thing;
> encourage more use of hashed inventory, hehe), but the advantage is that
> they no longer run into any --partial induced bug.

Removing the --partial flag would mean we could also remove code that is
only activated if the --partial flag is specified.  Also, if we removed
--partial, we could remove --checkpoint (at least from optimize), which
would remove a similar amount of code.

> Or maybe we could just add to the documentation that partial
> repositories should ideally be used only if you are only planning
> to get or pull, and not if you want to record/push/etc.

Possibly.  But just documenting that users should switch to --hashed format
as soon as possible sounds preferable.

> As a third option, darcs could explicitly keep track of whether the
> repository is in partial mode or not (which should be easy?), and
> either outright refuse to do certain tricky
> operations, or emit a warning to the effect of "This might break!"

This is my least favorite option:  it increases the complexity of the code
to support an obsolete feature, and at the same time fails to help those
folks who already have existing --partial repositories.
-- 
David Roundy
Department of Physics
Oregon State University

Based on our comments, I'll volunteer for a first attempt and making some
related documentation updates to steer people away from --partial.

On Fri, Feb 01, 2008 at 03:31:47PM -0000, David Roundy wrote:
> I agree with Mark on this.  We're giving up --partial repositories.
> And for --lazy repositories this message is exactly accurate: the
> source has disappeared, and we can't find those changes.
>
> status: chatting -> resolved

Pardon my ignorance, shouldn't that be -> resolved-in-unstable?

PS: is --lazy a post-2.0.0~pre2 addition?