Most of the time when I am working with darcs, I have absolutely no need to ever
go into the _darcs/ directory. Normally directories and files on *nix
(specifically, my Debian) only are visible if you would actually need to access
them for non-configuration related reasons. My search for a way to have darcs
use .darcs/ instead of _darcs/ failed- IRC and the darcs wiki did not turn up
anything useful. I realize that changing the directory for all users would be a
problem on Windows, but couldn't this at least be an option for *nix users?

The viability of the darcs dir has been discussed several
times and so far the _darcs side has always won.

There do is a serious practical problem with _darcs/ - many
tools recurse into _darcs/pristine/ and thus report bogus
mirror results, or even worse trash the pristine cache and
corrupts the repo.

This is not completely solved with .darcs/ since some tools
will recurse into a .darcs/pristine/ too.

The proposed and wanted fix for that problem is to turn
_darcs/pristine into a (binary) data base file.

On Mon, Feb 13, 2006 at 11:55:44AM +0000, Tommy Pettersson wrote:
> The viability of the darcs dir has been discussed several
> times and so far the _darcs side has always won.

Indeed.  For me, the deciding factor is that _darcs is never a small
directory, and I don't like the idea of hiding a directory that may be very
large.
-- 
David Roundy
http://www.darcs.net

/ to .darcs/

I probably don't go into the directory very often either.  But I find
it very useful to see that directory so I know that I am in a darcs
repository.

Those are all good arguments against making .darcs/ *mandatory*. Notice however,
that my wishlist item is for an *option*. Why should people like me (who know
they are in a darcs-covered directory and that it could be taking up a lot of
space- I doubt it does for the stuff I usually manage, small programs, config
files etc.) be forced to use _darcs?

On Mon, Feb 13, 2006 at 05:10:06PM +0000, maru dubshinki wrote:
> Those are all good arguments against making .darcs/ *mandatory*. Notice however,
> that my wishlist item is for an *option*. Why should people like me (who know
> they are in a darcs-covered directory and that it could be taking up a lot of
> space- I doubt it does for the stuff I usually manage, small programs, config
> files etc.) be forced to use _darcs?

As an optional change, .darcs wouldn't be bad.  We already support
_darcs/current/ vs _darcs/pristine/ and it probably wouldn't be too hard to
support either.  It might be a bit tricky in $HOME since ~/.darcs is the
default "prefs" directory.  Perhaps it should be _darcs vs .darcsrepo or
something.
-- 
David Roundy

Two comments (and another plea to do things the unix way):

1.  For the last couple of years that I've been tracking darcs, I've seen new
users request this change many times.  I haven't counted, but it appears that
new users are going to continue to ask for this.

2.  In many cases, those new users have encountered a problem where some tool
was automatically processing the _darcs directory as though it contained data
instead of metadata.  For example, the most recent case was that Eclipse was
compiling the source files inside _darcs, IIRC.  I myself have had this problem
on more than one occasion when using recursive unix commands such as a
"dos-to-unix-line-endings fixer".

2.a.  Of course, when this kind of problem occurs, we can always explain what
happened and suggest a work-around to make that tool stop doing that thing.  But
then a month later a different user, possibly using a different tool, encounters
the same kind of problem.

I think we should go with the unix tradition of using a leading dot to signal
that the directory contains metadata which is managed by a specific program, or
contains configuration files.

I don't oppose optional support for .darcsrepo, but I can't help
thinking that cvs is unix tradition too, and cvs users don't
complain regularly that the CVS meta dir isn't named .cvs.

That's a good point.  Why is that?  Perhaps it is that the tools, e.g. Eclipse,
have special-cases so that they don't go trying to compile files inside
directories named "CVS".

By the way, I'm afraid I'm personally not motivated by David Roundy's concern
about the weight of the directory.  I manage my disk usage with a recursive bash
script that calls "du -sk" on various directories.  Other people probably use
various tools that do the same.  Nowadays there are many tools that help you
analyze, visualize, or constrain disk usage.

Maybe it's just me, but I don't really care whether a big disk-munching
directory is named "_darcs" or ".darcs".  I would be interested to hear from
others about their disk-usage-management

This was discussed before.  The consensus was:

 - the default name will remain _darcs;
 - patches for making Darcs able to grok .darcs *in addition* to _darcs
   will be gratefully accepted.

So please feel free to implement support for .darcs.  You'll find some template
code in Repository.lhs, where we support both _darcs/current and _darcs/pristine.

On Fri, Mar 03, 2006 at 04:16:01PM +0000, Juliusz Chroboczek wrote:
> So please feel free to implement support for .darcs.  You'll find some template
> code in Repository.lhs, where we support both _darcs/current and _darcs/pristine.

Just pointing out that there may exist a .darcs directory in
user's home directory that is not a repo meta dir, so either
check for _darcs before .darcs when looking for a repo, or make
the dot-dir be called .darcsrepo or something.

On IRC just now on the #darcs channel I observed a new user having a problem
that I thought might be relevant.  There is no way to confirm this, but I wonder
if the new user, named Olivier, would have figured out his problem faster if the
meta-dir had been named ".darcs" so as to clue him in that it wasn't a directory
he was supposed to be working in.

*** olivier (n=chatzill@LAubervilliers-151-12-85-18.w193-252.abo.wanadoo.fr)
    has joined channel #darcs
<olivier> Hi everybody, completely new to darcs : wish to set up a local repos
	  of a distant one, and to visualise binaries file contained in. I've
	  done § darcs get http:// .., and after retreiving the repos, was
	  not able to "see" what 's in it. how to ? thks for your answers
<entropy> if you did a 'darcs get ....' and it succeeded, then you have
	  everything
<olivier> yes, so i cd to "fresh made" repos: .. _darcs/current, but size of
	  this one was unable to hold binaries (images in *.pdf)
<entropy> you should *never* go into _darcs/current  ... unless you know darcs
	  well and know exactly what you are doing
<entropy> that's the pristine tree that should *always* remain read-only to
	  the user. Only darcs itself should go in there and edit when changes
	  are recorded
<olivier> I've made it wit mc via putty, so maybe I've not let any "temp" file
<entropy> made what? I dont understard
<entropy> *understand
<olivier> I've installed darcs on a local ubuntu server wich I connect to with
	  a ssh/putty session on my winxp workstation. I've tryed to visualize
	  the local repos with mc, on the putty window, and on the server with
	  nautilus
<entropy> just browse all the files in the directory
<entropy> you dont need to go into _darcs
<entropy> everything within _darcs is the metadata for the repository
<entropy> the other files and directories are the current source
<olivier> I understand now : it was a pb of URL ! (I was too "high") thanks
	  for your answers, entropy
<entropy> no problem, glad I could help
<olivier> I've just set darcs repos "visible" via apache, following
	  http://www.darcs.net/manual/node4.html infos.
<olivier> I wish to have the nice darcs look, not the "ftp/directory listing"
	  style I get here
<entropy> olivier: http://users.auriga.wearlab.de/~alb/darcsweb/
<entropy> olivier: there are some of my repositories using darcsweb here (if
	  you need an example) => http://usrsrc.org/darcsweb/darcsweb.cgi
<^self> heh, darcsweb.cgi uses ; as query parameter separators, and not &
<^self> there are so few apps out there that do that
<^self> boo:
	http://usrsrc.org/darcsweb/darcsweb.cgi?r=vultures-screenshots;a=headblob;f=/bigroom-10-26-05.png
<olivier> entropy : thanks a lot. I'm  trying now to understand how to allow
	  CGIs inside /var/www/darcs/ : it's a pain to begin using a computer
	  at 33, because, as a "wanderer" in different domains (grphic, linux,
	  tex) I alxays feel an eternal begineer !

I've lost interest in this issue -- the core darcs developers aren't going to
change the default name from _darcs/ to .darcs/, and I don't think adding an
option would improve things.

Although I do feel compelled to add that I recently heard yet another story of
someone's tool automatically munging the contents of _darcs.  I can't remember
what tool it was now.

droundy's original reason not to use ".darcs" was that the contents of that
directory could be large and users might be unpleasantly surprised to find that
a "dot file" was so large.

However, over the years git, mercurial, and bzr have all started using .git,
.hg, and .bzr which contain complete history, so nowadays I guess users will not
be surprised that a revision control tool does this.  Indeed, it is getting to
the point that they would be surprised that darcs *doesn't* do it!

(And of course, .svn has always held an uncompressed pristine copy, which could
in some cases be larger than the history.)

Also, I just helped another user on IRC who didn't know how to make a tool (in
this case, bash) conveniently ignore the _darcs directory.

So I again ask darcs developers to reconsider this issue, in light of the
ongoing problems that people have configuring their tools to not recurse into
_darcs, and in light of the fact that ".$YOUR_TOOL_NAME" is now the de facto
standard among modern revision control tools.

I can only second this motion. We were using svn at my workplace, experimented 
with git but when darcs v2 came along we moved to darcs and my devteam was 
quite surprised at _darcs... it'd be nice to make this configurable.

I like _darcs.

I'm motivated by this item, so maybe at some point when I have a Round Tuit I'll
learn some Haskell and try to write a patch that makes ".darcs" optional.  By
the way, part of the reason I'm motivated is that I just now stumbled on yet
another tool that recurses into _darcs by default but not into directories that
begin with ".".  It is David Wheeler's "SLOCCount".

I think we ought to do this; it seems to be a standard DVCS practice these days.

Anyway, the question becomes how to do it. The obvious way is to make it a
compile-time option with CPP and so on (default being _darcs and adding a switch
to configure.ac to make it .darcs). This is pretty easy; I might just do it
today or tomorrow anyway.

But I am unsure how to do it at runtime. Obviously you could define some sort of
repoDir :: IO Maybe String', which would basically be = checkIfDirectoryExists
"./_darcs/" >> return Just "_darcs" `catch` checkIfDirectoryExists "./.darcs/"
>> return Just ".darcs" `catch` return Nothing. (Well, you see what I mean.)

Problem is, "_darcs" is used in *so* many places that doing redundant file
operations each time would be very inefficient, and it might well screw up for
functions which aren't already in the IO monad. A better way would be to check
once and then save the result as a string constant, but I don't know any way
other than a global variable to do that, and Haskell doesn't Do global variables.

Anybody have coding thoughts?

If you are coding this then consider .darcsrepo or something. My users have 
their branches in their homedir.

> If you are coding this then consider .darcsrepo or something. My  
> users have
> their branches in their homedir.

+1 for .darcsrepo

Regards,

Zooko

("+1" means I support the idea.)

>  A better way would be to check
>  once and then save the result as a string constant, but I don't know any way
>  other than a global variable to do that, and Haskell doesn't Do global variables.
>
>  Anybody have coding thoughts?

Global wouldn't be enough; it'd have to be something you associate
with each Repository type.  Consider pulling from multiple
repositories, some of which have _darcs, others .darcsrepo

I suspect this one of those things which aren't really worth the
effort.  Then again, maybe trying to do this would result in some kind
of cleanup.

Also, another issue to consider is that repositories created with
.darcsrepo instead of _darcs would not be backwards-compatible.  Older
darcs would not be able to get or pull from them (unless you put a
symlink, which may defeat the purpose).  I guess that's not too big a
deal if the default is _darcs, and .darcsrepo is only used in cases
where the repository is local-ish.

Well, on the subject of naming, I saw "._darcs" suggested - which certainly has
the virtue of uniformity.

As for symlinking: that might not be a bad idea. Does anyone (zook?) know
whether the misbehaving tools who partially motivate this feature follow
symlinks? If they don't, then symlinking would be a good way to both preserve
backwards compatibility and to get the anti-tool effect.

I don't know which tools follow symlinks and which don't, by default. 
Nonetheless, I would support preserving optional backwards-compatibility for a
while, in order to eventually have a ".darcsrepo", which in addition to avoiding
some tools, is also convenient for users of the "*" glob pattern in unix shells,
and is consistent with .hg, .bzr, and .git.

I was working with my company's Operations/SysAdmin man today, and this exchange
occurred:

Zooko: By the way, I have a user interface question for you: would you prefer if
it were named .darcs instead of _darcs? :-)
Zandr: Yes, I'd prefer .darcs.  more consistent with the rest of the known universe
Zooko: Duly noted.

As an alternative, have the repository directory be .darcs/_darcs (or rater
.darcsrepo/_darcs).
While it is a hack, it has several advantages:

-New repositories are identifiable through their url: /path/.darcsrepo versus /path/

-Old darcs would be able to work with newrepositories

-Tools would not recurse into that directory

-There would be no need to stat several files when pulling/getting a repository