Hi, Again another case where it may have made sense to send the refactor and the new help separately so that I can mindlessly apply one and then choose to hold off on another. (I could be mistaken about this, or contradict myself tomorrow, it's one of those more-art-than-science issues, how to divide things up into patches nicely, sorry for flip-flopping).
Can somebody help review Trent's new text? Simon, are you available to do this? From my cursory glance, it seems quite helpful. Just one comment below re: hard-linking On Sat, Dec 13, 2008 at 01:50:18 -0800, Trent W. Buck wrote: > | Get creates a local copy of a repository. The optional second > | argument specifies a destination directory for the new copy; if > | omitted, it is inferred from the source location. > | > | By default Darcs will copy every patch from the original repository. > | This means the copy is completely independent of the original; you can > | operate on the new repository even when the original is inaccessible. > | If you expect the original repository to remain accessible, you can > | use --lazy to avoid copying patches until they are needed (`copy on > | demand'). This is particularly useful when copying a remote > | repository with a long history that you don't care about. > | > | The --lazy option isn't as useful for local copies, because Darcs will > | automatically use `hard linking' where possible. As well as saving > | time and space, you can move or delete the original repository without > | affecting a complete, hard-linked copy. Hard linking requires that > | the copy be on the same filesystem and the original repository, and > | that the filesystem support hard linking. This is usually the case, > | except for Windows versions prior to Vista. I don't think we have /any/ hard linking support for Windows, but I would heartily welcome a patch that provided it at least for Vista. Salvatore? I believe the request is on the bugtracker somewhere. > | It is often desirable to make a copy of a repository that excludes > | some patches. For example, if releases are tagged then `darcs get > | --tag .' would make a copy of the repository as at the latest release. > | > | An untagged repository state can still be identified unambiguously by > | a context file, as generated by `darcs changes --context'. Given the > | name of such a file, the --context option will create a repository > | that includes only the patches from that context. When a user reports > | a bug in an unreleased version of your project, the recommended way to > | find out exactly what version they were running is to have them > | include a context file in the bug report. > | > | You can also make a copy of an untagged state using the --to-patch or > | --to-match options, which exclude patches `after' the first matching > | patch. Because these options treat the set of patches as an ordered > | sequence, you may get different results after reordering with `darcs > | optimize', so tagging is preferred. > | > | If the source repository is in a legacy darcs-1 format and contains at > | least one checkpoint (see `darcs optimize), the --partial option will > | create a partial repository. A partial repository discards history > | from before the checkpoint in order to reduce resource requirements. > | For modern darcs-2 repositories, --partial is a deprecated alias for > | the --lazy option. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
pgpZlqcS2VQFV.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
