I'm not sure if this is a bug, but it is causing
an error in the filestore tests.

1.  Create a file, foo, with contents "bar".
2.  darcs init
3.  darcs add foo
4.  darcs record
5.  darcs log --xml # to get the hash
6.  darcs show contents foo --match 'hash 20150403053308-0f649-b1eb60ba7610b6a71c09804439fc9ce61d5cd0fa'  # shows "bar"
7.  darcs remove foo
8.  darsc record
9.  darcs show contents foo --match 'hash 20150403053308-0f649-b1eb60ba7610b6a71c09804439fc9ce61d5cd0fa'  # shows nothing (empty)

I would have thought that (6) and (9) would produce the same output.

Is there any way to get the contents of an earlier version of a file
that has been removed from the repository?

John

On Fri, Apr 3, 2015 at 2:34 AM, John MacFarlane <bugs@darcs.net> wrote:

>
> New submission from John MacFarlane <jgm@berkeley.edu>:
>
> I'm not sure if this is a bug, but it is causing
> an error in the filestore tests.
>
> 1.  Create a file, foo, with contents "bar".
> 2.  darcs init
> 3.  darcs add foo
> 4.  darcs record
> 5.  darcs log --xml # to get the hash
> 6.  darcs show contents foo --match 'hash
> 20150403053308-0f649-b1eb60ba7610b6a71c09804439fc9ce61d5cd0fa'  # shows
> "bar"
> 7.  darcs remove foo
> 8.  darsc record
> 9.  darcs show contents foo --match 'hash
> 20150403053308-0f649-b1eb60ba7610b6a71c09804439fc9ce61d5cd0fa'  # shows
> nothing (empty)
>
> I would have thought that (6) and (9) would produce the same output.
>
> Is there any way to get the contents of an earlier version of a file
> that has been removed from the repository?
>

darcs annotate foo --match 'hash
20150403053308-0f649-b1eb60ba7610b6a71c09804439fc9ce61d5cd0fa' # shows
"bar" + other metadata.

I reported this problem over here too:
http://comments.gmane.org/gmane.comp.version-control.darcs.devel/16530

It looks like a bug to me.

-Andreas

----------
> messages: 18340
> nosy: jgm
> status: unknown
> title: get contents of deleted file
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue2447>
> __________________________________
> _______________________________________________
> darcs-devel mailing list
> darcs-devel@darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-devel
>

Attachments

• unnamed

This is a bug indeed but it goes deeper.

As I tried to explain in an earlier answer to the list, the real problem
is that the options --match, --hash, --patch, and --index to "darcs show
contents" are all ill-defined: it makes no sense to select a *single*
patch and then ask "what are the contents of file xxx after applying
this patch?". Because that depends on the context (=state of the repo)
in which you apply the patch.

The same problem exists, BTW, for the commands: show files, dist, and
annotate.

What you want is another set of options: --to-match, --to-hash,
--to-patch, and --to-index that give you the state of the repo after
applying all patches up to the one selected. These options implicitly
depend on the current order of patches in the repo.

For compatibility we could continue to support the old options as
aliases for the --to- variants in the case of the affected four commands.

Added a test for this (patch1361).

Let's separate the UI design question from the actual bug. Sorry for
confusing these. I'll open another issue for the UI part (i.e. rename
the options to --to-xxx and make sure the docs explain that they choose
everything up to the /last/ matching patch).

I checked that show files, dist, and annotate are *not* affected by this
bug. Indeed, what they do is interpret --hash and co. as --to-hash, even
though this is not too apparent in the code. Even show contents tries to
do that (but sometimes fails). See patch1366 for a resolution.

The following patch sent by Ben Franksen <benjamin.franksen@helmholtz-berlin.de> updated issue issue2447 with
status=resolved;resolvedin=2.12.0 HEAD

* resolve issue2447 by using getNonrangeMatch as in ShowFiles 
Ignore-this: 3fe5a3ecf764b4743963c6f5cdd23d14

The crucial change here is that we don't use readRecorded if called with a
match option. Instead we call getNonrangeMatch in an empty (temporary) tree,
quite similar to how this is done in D.UI.Command.ShowFiles.

This patch also refactors the code quite a bit and adds some comments to
explain the tricky bits.