Okay, thanks. So the rumors about this must be incorrect? On Wed, Apr 1, 2009 at 9:57 PM, Ketil Malde wrote:

Don Stewart writes:

...

...

Rumor goes that this is very difficult to do with Darcs. Is this correct?

...

darcs unpull

Or just cd to a different directory, and darcs get -t <version you want>?

-k -- If I haven't seen further, it is by standing in the footprints of giants

Perhaps the rumours refer to non-tagged "versions"? In conventional non-distributed version control systems, one might go back to the version on a specific date, while with darcs, that only makes sense wrt a specific repo (I think?). So you can unpull all patches after a date from your local repo, but that doesn't mean that you get a repo that matches someone else's repo after they perform the same procedure. If both parties commit to a central repo, and pull all changes via that, there is a greater chance of date-based synchronicity. Claus

Yes. It would be fairly easy to check this in the docs, too :)

bugfact:

...

Okay, thanks. So the rumors about this must be incorrect?

On Wed, Apr 1, 2009 at 9:57 PM, Ketil Malde wrote:

Don Stewart writes:

>> Rumor goes that this is very difficult to do with Darcs. Is this correct?

> darcs unpull

Or just cd to a different directory, and darcs get -t <version you want>?

-k -- If I haven't seen further, it is by standing in the footprints of giants

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, Apr 1, 2009 at 11:25 PM, Claus Reinke wrote:

...

Perhaps the rumours refer to non-tagged "versions"? In conventional non-distributed version control systems, one might go back to the version on a specific date, while with darcs, that only makes sense wrt a specific repo (I think?).

On Wed, Apr 01, 2009 at 23:43:36 +0200, Peter Verswyvelen wrote:

Yes, that might be the rumor indeed, it surely sounds like it :) Darcs is really very different, so it takes a while to get used to it when coming from other systems.

This has been said in one of the earlier responses, but I thought it was worth repeating: darcs has a notion of context files which can be used to retrieve exactly another version of a repository with darcs get --context name-of-file. You can generate such files by invoking darcs changes --context. For that matter, patch bundles (as created by darcs send) can also be used as context files. It's sometimes quite handy to do something like darcs get --context foo.dpatch to retrieve exactly the version of the repository a patch bundle was meant to apply to. This is one of the little known features of darcs, and should probably appear in some kind of darcs tips series of blog articles :-) -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9

Excerpts from Peter Verswyvelen's message of Wed Apr 01 23:39:15 +0200 2009: [...]

biggest problems I usually see in teams - namely forgetting to add files, forgetting to check in dependencies and the inability the merge after renames or moves -

Have a look at the --look-for-adds flag that makes the enables the detection of new files. Removing files is already detected and moving should be done with "darcs mv" which makes it pretty close to what one can expect. Best regards, -- Nicolas Pouillard

Peter Verswyvelen writes:

Forgetting to add a file can be a nasty one, since if you discover that too late, the original file at patch time might not exist anymore (how do you guys solve this? Just plain discipline I guess?).

I've done this once, but with the cabal dependencies, not darcs. Thus the uploaded sdist was missing one of the source files, and consequently failed to build. I suppose the best way is to test this with a separate test repository which you don't touch, except from pulling from your development repo and checking that it builds. -k -- If I haven't seen further, it is by standing in the footprints of giants

Simon Michael writes:

I'm learning useful things in this thread.

Ketil Malde wrote:

...

I've done this once, but with the cabal dependencies, not darcs. Thus the uploaded sdist was missing one of the source files, and consequently failed to build.

I have a pre-release make target where I test everything I can think of. I think it prevents the above, am I right ?

Dunno.

# run pre-release checks: cabal is happy, the code builds, tests pass.. check: setversion unittest doctest haddocktest cabal clean cabal check cabal configure cabal build

dist/build/hledger/hledger test 2>&1 | tail -1 | grep -q 'Errors: 0 Failures: 0' |

You'd also want to test cabal haddock cabal test cabal copy "$(TMPDIR="$PWD" mktemp -dt yow.XXXXXX)" # untested IMO even if your tests aren't implemented in Setup.lhs, you should still teach "cabal test" how to run them. That helps distributors like me automatically run the test -- i.e. you get testing "for free" because we don't have to go out of our way to turn it on.

Regarding these files that people forget to checkin. Doesn't every project have a well define directory structure? Shouldn't the "prefs/boring" file use this fact to encapsulate the rules of file inclusion and exclusion? Isn't it safer to checkin too many files (by accident) than forgetting one? Shouldn't this behavior be the default? To me version control also means "if it works on my machine, it should work on all other peoples machines after they are in synch". Of course in reality people can also have different environment variables, different versions of operating systems, different hardware, etc so this idea certainly is utopia (however the version control system "VESTAhttp://sourcefrog.net/weblog/software/vc/vesta/index.html " tried to version everything, they even considered versioning the operating system :-) On Fri, Apr 3, 2009 at 11:23 AM, Malcolm Wallace < Malcolm.Wallace@cs.york.ac.uk> wrote:

...

...

Thus the uploaded sdist was missing one of the source files, and consequently failed to build.

I have a pre-release make target where I test everything I can think of. I think it prevents the above, am I right ?

Not unless you run 'make check' in a separate pristine copy of the repo.

The problem occurs when your local development repo contains some essential files that have not been checked into the VCS. Your 'make check' will work fine for you, but not for other people.

Regards, Malcolm _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Okay. I always put these in the boring file. Matter of taste I guess. On Fri, Apr 3, 2009 at 3:18 PM, Ketil Malde wrote:

Peter Verswyvelen writes:

...

Regarding these files that people forget to checkin. Doesn't every project have a well define directory structure? Shouldn't the "prefs/boring" file use this fact to encapsulate the rules of file inclusion and exclusion? Isn't it safer to checkin too many files (by accident) than forgetting one? Shouldn't this behavior be the default?

IMO: No. My development directories tend to litter up with files containing test input data, output data, profiling data, and all kinds of junk. Better to occasionally forget a file and get an error message in the mail when somebody else tries to use it (i.e. non-strictly) than have my darcs repository and Hackage sdists working but littered with junk. (My current testing involves 118GB of input data, you sure you want to see that on Hackage? :-)

-k -- If I haven't seen further, it is by standing in the footprints of giants

Peter Verswyvelen wrote:

Okay, thanks. So the rumors about this must be incorrect?

That's one rumor I've never heard. Do drop by #darcs as well, we love solving easy problems. :)

Henning Thielemann writes:

On Wed, 1 Apr 2009, Don Stewart wrote:

...

bugfact:

...

Rumor goes that this is very difficult to do with Darcs. Is this correct?

darcs unpull

Be careful - you cannot revert this! If you want to unpull patches, that were not distributed so far, you should better call 'darcs get' to get a copy of the repository and then run 'darcs unpull' in this copy.

For the record, unpull is now called "obliterate", and "unpull" is an alias for it. This new name is meant to instill caution in the user :-)