[darcs-users] Cheap branches (was: Re: post-1.0: "isolated directories"?)

Sun Oct 17 07:36:24 UTC 2004

Okay, the last two times I tried replying to this my laptop died. Third
time lucky! :)

On Fri, Oct 15, 2004 at 08:43:48AM -0400, David Roundy wrote:
> > 	darcs push darcs-repo:azure.humbug.org.au/darcs-repo/experimental
> Hmmm.  Looks like a nice start.  

Excellent :)

> Using a cgi script like this certainly looks like a good idea.  The hooks
> for DARCS_SSH etc are clever, but a bit scary in light of the recent work
> to switch to sftp from scp.  Still, it shouldn't be hard to iron out.

Yeah, the DARCS_SSH hooks suck; but it was an easy way to avoid having
to actually touch darcs itself :)

> > Other notes: this explicitly doesn't require darcs (or haskell) on the
> > server -- the scripts are all perl and bash. 
> This is definitely nice.  One common complaint is the requirement of push
> that darcs be on the server.

Yeah; and if you don't want any advanced features, the darcs stuff is
simple enough that that doesn't seem necessary.

> > I blogged more details at: http://azure.humbug.org.au/~aj/blog/2004/10/14
> > There's a tarball up at: http://azure.humbug.org.au/~aj/darcs-repo/
> Hmmm.  Wouldn't it make sense to make this a darcs repo? 

Heh. It mostly isn't because the first time I collected all the bits
in one place was on a server that doesn't have darcs on it. :)

http://www.erisian.com.au/darcs/darcs-repo/mainline

> I like the fact
> that you have perl code to create patch names, etc.  In general, perhaps a
> perl module to parse (and maybe apply, eventually) darcs patches would be
> interesting.

Yeah, parsing seems necessary so you can work out when the "}" line
is closing a patch rather than the contents of a "setpref" line or
similar. And applying seems fairly easy too; possibly apart from the
"merger/regrem" patches?

> (from blog):
> > Missing features? Creating new projects and branches has to be done
> > manually (with a mkdir and a touch inventory-branch respectively).
> If we could make DARCS_SCP figure out how to call the cgi script rather
> than running scp itself (which would seem like a good plan), then creating
> new repos (idea below being to eliminate the project/branch distinction)
> could consist of pushing to a new project name.  

Yeah - the darcs-scp script translates to "ssh <blah> darcs-repo get
.." already anyway; and darcs-ssh just goes to "ssh <blah> darcs-repo
apply ..". So that's pretty easy -- it just means making "darcs-repo
apply" create an inventory file.

> You'd just have to make
> the cgi script return an empty repository when its asked for a repository
> it doesn't yet have.

(The CGI script just calls "darcs-repo get")

> > [0] The repo structure looks like:
> > 	/srv/darcs-repo/
> > 		{project name}/
> Could we do without the {project name}? I don't think there's any reason to
> break the darcs-repo into separate projects, each of which has its
> branches.  In a sense, we could view all projects as being branches of the
> null repository.  I think this would make things simpler, without any
> significant cost.

Hrm, that's true. I kind-of like the idea of having separate repositories
on a single server, though, just so I can keep track of things -- like
say "du darcs-repo/foobar" to see how much space the foobar repo's taking
up. Splitting them up by project seems about the right level to do that;
since sharing patches across projects is pretty unlikely.

> Also, if we allow the branch name to contain /'s (perhaps escaped), we
> could perhaps emulate a full directory structure, so the user could have
> the effect of branches by naming their projects foo/head, foo/unstable,
> etc.

Yeah. For the moment it's a two-level thing -- you get "project foo"
and "branch head"; if you want more levels you have to use hyphens or
similar instead of slashes. *shrug* I prefer to start off limited and
add features later :)

> > 			inventory-{branch name}
> It looks like you only support here a flat inventory? This can be a major
> slowdown as repositories get old (and have lots of patches), which is why
> it's broken up into _darcs/inventory followed by
> _darcs/inventories/{patchname}. 

Right, I don't understand this. Hrm, the manual doesn't seem to mention
"inventories" anywhere; is there an english explanation of what's going
on with that anywhere? I guess this is what happens when you "checkpoint"?

> I don't think this is a fundamental
> problem, but needs to be done right, since you can only break the inventory
> at tags, and only if the tag contains all the patches prior to itself (poke
> me if I am unclear here).

So, it sounds like this is what I want to be able to hook my
"mainline--0.1" and "mainline--0.2" branches together, without bogging
down in all the old history unless I decide I need it?

Hrm, maybe it'd make more sense to me if I asked this slightly
differently. One of the the DarcsWiki wishlists is "I wish the repo
browser had a 'download tarball'"; I'd like my "darcs-repo" to be able
to do that too, though obviously it's a way away from that now. So, say
I have versions 0.1.1 - 0.1.17 and 0.2.1 - 0.2.45; where each version
has a tag, and there are possibly many patches between each version. I
don't mind having to download every patch since 0.1.1 to darcs get 0.1.17,
but I don't want to have to get all those patches when I'm getting 0.2.1.

How would I structure this? As two branches? Or as a single branch,
with a checkpoint at 0.2.1? If I do it as two branches (so I can later
release a 0.1.18 if I need to), can I still get "darcs changes" to go
all the way back to 0.1.1? If someone else adds a patch to 0.1.16 and I
want to pull that forward into 0.2.46, can darcs magically get the patch
for 0.1.17 so it can commute it up to 0.2.1 then all the way to 0.2.46?

Hrm, I took the opportunity to add

   http://www.scannedinavian.org/DarcsWiki/BestPractices

and included some babble. Maybe others would like to add questions
or improve answers or just add some links to other threads that are
enlightening?

> > 			patches/
> > 				{original patch name (uncompressed)}
> > 				{original patch name (uncompressed)}.{branch}
> In my less-nested picture, there would be ambiguity about the original
> patch name.  

Not really, it'd just mean doing, say:

	/srv/darcs-repo/
		patches/
			{patch name}
		some/branch/name/
			inventory
			commuted-patches/
				{patch name}
		some/other/branch/
			inventory
			commuted-patches/
				{patch name}
				{patch name}

(The theory is you either just grab the first checked in patch of the
right name; or else there's a branch specific diff that you apply to
the first checked in patch to get what you need.)

But like I said, I do like having each project's patches physically
separated.

Maybe you could instead have a file in /etc that maps branch-prefixes to
different repositories? So you could have

	/etc/darcs-repo.conf
		repo "foobar/experimental" = /srv/foobar/experimental/darcs
		repo "foobar" = /srv/foobar/darcs
		repo "aj" = /home/aj/darcs
		default-repo = /srv/darcs-repo/

and then say

	darcs-repo get foobar/experimental/blah/mainline/0.1 inventory

or whatever you like, with darcs-repo automatically deciding whether
that's part of the default repository, or the foobar repository, or the
"foobar/experimental" repository, or whatever?

Then if you want all your patches shared for all projects, you just set
a default-repo, and ignore the other issues.

Oh, the other reason I like having projects in different directories is
so I can use permissions to control access.

> Might it be easier to use rcs for this? 

Hrm, diff/red are pretty easy; but rcs is pretty easy too. Though rcs
is more designed for incremental changes, whereas I think darcs' usage
is more along the lines of a variety of minor changes to an original,
rather than cumulative changes?

Cheers,
aj

-- 
Anthony Towns <aj at humbug.org.au> <http://azure.humbug.org.au/~aj/>
Don't assume I speak for anyone but myself. GPG signed mail preferred.

``[S]exual orgies eliminate social tensions and ought to be encouraged.''
      -- US Supreme Court Justice Antonin Scalia (http://tinyurl.com/3kwod)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20041017/f875b6b9/attachment.pgp 