On Mon, 8 Oct 2007 02:55:37 +0200, Frank Lichtenheld <[EMAIL PROTECTED]> said:
> On Sun, Oct 07, 2007 at 06:24:15PM -0500, Manoj Srivastava wrote: >> On Sun, 7 Oct 2007 22:04:21 +0200, Frank Lichtenheld >> <[EMAIL PROTECTED]> said: >> > bzr and git always ship the complete repository with each working >> > directory. This is why they are called "distributed". Arch seems to >> > be some weird thing in between truly central and truly distributed >> > VCS. >> >> I am not sure I see this. Arch repositories are distributed, and you >> can pull, branch, and tag off any repository out there in the >> meta-verse. But every directory also has a semi permanent URI; and >> checking out a branch locally does not end up with you downloading >> the terabytes of stuff in the repo out there. > Lets not exagerate. At least for git the repository will usually be > smaller or only little larger than the working directory. It will > probably compress worse though. How is this magic done? If I have several dozen feature branches, all feeding back and forth, and have made lots and lots of changes in my sources, how does git preserve all this information without a commensurate increase in size? This makes the information theory geek in me very very skeptical. Or are you talking about "typical" usage, and is that why people go around making "shallow" copies to cut down on the size of the shipped repo? >> This might be because you can have more than one project in a repo; >> my repo contains CVS emacs, unicode emacs, as well as most of the >> SELinux packages, etc, and I mirror partially to arch.d.o. I would >> hate to see all of emacs in the local dir of people who just want to >> check out devotee. >> >> So arch does have a different mechanism of doing distributed >> repositories; but the repositories are distributed in the sense that >> I control one repo, but branches in my repo are children of other >> repositories, and can be merged and tagged back and from, > Out of interest, which of the following actions would need remote > access? > log view (including diffs between revisions) The ./{arch} directory does contain logs. Diffs between revisions requires access to the repository (or the local cache library, if that contains the revision we want to diff with or from) > annotation/blame view Same thing; you need access to the repo since the code for the other revisions is not in the checked out directory. > creating a new commit/revision/tag Committing it would require access to the repo. > reverting a dirty working tree to a clean one I think you are talking about reverting local changes to the latest revision from the repository. Well, that needs acess to the repo or a local cache. > For git/bzr, the answer is usually "no" to all of these. If you have a > "shallow copy" in git, the answers to the first two become "yes, since > you will need it convert to a full copy first" . For arch, the answer is yes to all these cases. > [...] >> Assuming we consider trying to support arch-like distributed version >> control systems in the new dpkg; it might well be that the current >> approach is too focussed on git/bzr type version control to work well >> with arch. > It most probably is. As far as I can tell, most of the things being done for git are not required if I ship a working directory for for arch ({arch} and .arh-ids); and the only other thing required would be to also ship what lives in the grab file in the control file; so people can know where to register the archive location from to get access to the other information. If people wanted to provide changes, all that is needed is for them to tag the developers branch, hack, and ask the developers to pull from their branch (people have done that for ucf and devotee in the past). What exactly is the goal of this dpkg addition? With arch, I can ship a full working copy; and as long as people have the repository registered, they have full access to older revisions and feature branches and all. Would shipping the full working dir get by the requirement of shipping the diff.gz? If so, we can support arch with no changes to dpkg whatsoever. manoj -- You never hesitate to tackle the most difficult problems. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]