Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[question] the "dataset id" is meant to be the same for all siblings, correct? #2801

Closed
notestaff opened this issue Sep 7, 2018 · 4 comments
Closed

[question] the "dataset id" is meant to be the same for all siblings, correct? #2801

notestaff opened this issue Sep 7, 2018 · 4 comments
Labels
documentation Documentation-related issue question Issue asks a question rather than reporting a problem

Comments

@notestaff
Copy link

Just to confirm my understanding: unlike git-annex's repository uuid, which denotes a specific copy of the repository, and is different for different copies, Datalad's "dataset id" is meant to be the same across all siblings and all branches of a dataset? @yarikoptic
@yarikoptic-gitmate
Copy link
Collaborator

GitMate.io thinks possibly related issues are #1028 (Dataset singletons), #656 (ADHD200 dataset), #804 (Dataset() should be hashable), #2762 (Documentation - dataset.siblings() does not have result_renderer to None by default), and #36 (Mitchell's dataset).

@kyleam
Copy link
Contributor

kyleam commented Sep 7, 2018

Yes, that's correct.

@yarikoptic yarikoptic added the question Issue asks a question rather than reporting a problem label Sep 7, 2018
@yarikoptic
Copy link
Member

Correct! It is the "identity" of the DataLad dataset, so later on we could identify clones of the same dataset.
We considered alternatives (e.g. hexsha of the first left most commit in the history etc) but none provided robust way to say "this is some version of the dataset X", so every dataset now gets its ID upon creation. You can use datalad create --force REPO to initiate such .datalad/config in an existing git or git-annex repository.
For completeness, altogether following "ids" could be identified which serve different identification purposes

  • DataLad dataset id (datalad.dataset.id config, typically in custom .datalad/config to be carried along with dataset) - identify the entire dataset (at any version or location)
  • Git-annex uuid (annex.uuid config, in .git/config) - identity of a git clone of a dataset. So each DataLad dataset id could have multiple Git-annex uuids
  • Commit id (hexsha, or a tag, stored in git history) - identifies a version within a particular dataset. Typically unique to a DataLad dataset id, but it is possible that multiple DataLad datasets could have some common ancestor (e.g. from a template repo, thus shared commits), but different DataLad dataset ids
  • git-annex key (typically some checksum, stored in git) - identifies the content of (version of) a file, as stored in git using git-annex. The same key could be present in multiple datasets, so not necessarily uniquely associated with any of them.

@mih mih added the documentation Documentation-related issue label Sep 8, 2018
@mih
Copy link
Member

mih commented Sep 8, 2018

I am reopening this, as this info should be in the docs.

@mih mih reopened this Sep 8, 2018
yarikoptic added a commit that referenced this issue Sep 9, 2018
@yarikoptic
Merge pull request #2809 from mih/id-docs
3f18f6f 
DOC: Info on IDs (fixes gh-2801)

[ci: skip]
yarikoptic added a commit that referenced this issue Sep 13, 2018
@yarikoptic
Merge tag '0.10.3' into debian
43e879d 
0.10.3 (Sep 13, 2018) -- Almost-perfect

This is largely a bugfix release which addressed many (but not yet all)
issues of working with git-annex direct and version 6 modes, and operation
on Windows in general.  Among enhancements you will see the
support of public S3 buckets (even with periods in their names),
ability to configure new providers interactively, and improved `egrep`
search backend.

Although we do not require with this release, it is recommended to make
sure that you are using a recent `git-annex` since it also had a variety
of fixes and enhancements in the past months.

Fixes

- Parsing of combined short options has been broken since DataLad
  v0.10.0. ([#2710])
- The `datalad save` instructions shown by `datalad run` for a command
  with a non-zero exit were incorrectly formatted. ([#2692])
- Decompression of zip files (e.g., through `datalad
  add-archive-content`) failed on Python 3.  ([#2702])
- Windows:
  - colored log output was not being processed by colorama.  ([#2707])
  - more codepaths now try multiple times when removing a file to deal
    with latency and locking issues on Windows.  ([#2795])
- Internal git fetch calls have been updated to work around a
  GitPython `BadName` issue.  ([#2712]), ([#2794])
- The progess bar for annex file transferring was unable to handle an
  empty file.  ([#2717])
- `datalad add-readme` halted when no aggregated metadata was found
  rather than displaying a warning.  ([#2731])
- `datalad rerun` failed if `--onto` was specified and the history
  contained no run commits.  ([#2761])
- Processing of a command's results failed on a result record with a
  missing value (e.g., absent field or subfield in metadata).  Now the
  missing value is rendered as "N/A".  ([#2725]).
- A couple of documentation links in the "Delineation from related
  solutions" were misformatted.  ([#2773])
- With the latest git-annex, several known V6 failures are no longer
  an issue.  ([#2777])
- In direct mode, commit changes would often commit annexed content as
  regular Git files.  A new approach fixes this and resolves a good
  number of known failures.  ([#2770])
- The reporting of command results failed if the current working
  directory was removed (e.g., after an unsuccessful `install`). ([#2788])
- When installing into an existing empty directory, `datalad install`
  removed the directory after a failed clone.  ([#2788])
- `datalad run` incorrectly handled inputs and outputs for paths with
  spaces and other characters that require shell escaping.  ([#2798])
- Globbing inputs and outputs for `datalad run` didn't work correctly
  if a subdataset wasn't installed.  ([#2796])
- Minor (in)compatibility with git 2.19 - (no) trailing period
  in an error message now. ([#2815])

Enhancements and new features

- Anonymous access is now supported for S3 and other downloaders.  ([#2708])
- A new interface is available to ease setting up new providers.  ([#2708])
- Metadata: changes to egrep mode search  ([#2735])
  - Queries in egrep mode are now case-sensitive when the query
    contains any uppercase letters and are case-insensitive otherwise.
    The new mode egrepcs can be used to perform a case-sensitive query
    with all lower-case letters.
  - Search can now be limited to a specific key.
  - Multiple queries (list of expressions) are evaluated using AND to
    determine whether something is a hit.
  - A single multi-field query (e.g., `pa*:findme`) is a hit, when any
    matching field matches the query.
  - All matching key/value combinations across all (multi-field)
    queries are reported in the query_matched result field.
  - egrep mode now shows all hits rather than limiting the results to
    the top 20 hits.
- The documentation on how to format commands for `datalad run` has
  been improved.  ([#2703])
- The method for determining the current working directory on Windows
  has been improved.  ([#2707])
- `datalad --version` now simply shows the version without the
  license.  ([#2733])
- `datalad export-archive` learned to export under an existing
  directory via its `--filename` option.  ([#2723])
- `datalad export-to-figshare` now generates the zip archive in the
  root of the dataset unless `--filename` is specified.  ([#2723])
- After importing `datalad.api`, `help(datalad.api)` (or
  `datalad.api?` in IPython) now shows a summary of the available
  DataLad commands.  ([#2728])
- Support for using `datalad` from IPython has been improved.  ([#2722])
- `datalad wtf` now returns structured data and reports the version of
  each extension.  ([#2741])
- The internal handling of gitattributes information has been
  improved.  A user-visible consequence is that `datalad create
  --force` no longer duplicates existing attributes.  ([#2744])
- The "annex" metadata extractor can now be used even when no content
  is present.  ([#2724])
- The `add_url_to_file` method (called by commands like `datalad
  download-url` and `datalad add-archive-content`) learned how to
  display a progress bar.  ([#2738])

* tag '0.10.3': (214 commits)
  Changelog entry for 2.19 git compat fix
  DOC: slight tune ups to the ChangeLog
  ENH: link issue/pull #s in CHANGELOG, use tools/link_issues_CHANGELOG
  BF: remove trailing period while matching a mesage from git
  DOC: try_multiple_dec: Add description of `duration` parameter
  CLN: annexrepo: Fix grammar in a recently added comment
  TST: auto: Reformat comment from 900ee08
  DOC: _rmtree: Drop a word from summary line
  DOC: Info on IDs (fixes gh-2801)
  BF: diff -- when reraising - just raise, do not raise that instance of exception from new location
  BF(TST): precommit before removing submodule so there is no batched processes
  ENH+BF(TST): close established ssh sockets upon test finish
  BF(TST): One more "clost all log handlers in the test"
  CHANGELOG.md: Start adding entries for v0.10.3
  BF(TST): close cookies db in the teardown since atexit is later, so cannot assure no open files
  BF(TST): explicitly close created log handlers
  ENH(TST): @known_failure_windows to replace plain @skip_if_on_windows where there is hope
  BF(TST): do not swallow output while testing AutomagicIO to not cause some open files issue
  ENH(TST): Skip a test when cannot remove curent directory
  BF(TST): explicitly precommit a repo used under swallow_outputs
  ...
@yarikoptic-gitmate yarikoptic-gitmate mentioned this issue Sep 13, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
documentation Documentation-related issue question Issue asks a question rather than reporting a problem
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@yarikoptic @mih @kyleam @notestaff @yarikoptic-gitmate