On Sun, 7 Oct 2007 22:04:21 +0200, Frank Lichtenheld <[EMAIL PROTECTED]> said:
> On Sun, Oct 07, 2007 at 02:16:12PM -0500, Manoj Srivastava wrote: >> On Sun, 7 Oct 2007 20:33:58 +0200, Frank Lichtenheld >> <[EMAIL PROTECTED]> said: >> > On Sun, Oct 07, 2007 at 10:49:48AM -0500, Manoj Srivastava wrote: >> > You probably mean source package here and not .deb. Also the >> > original proposal just means shipping the repository data, since >> > most DVCS can easily create a working directory from that. >> >> Hmm. The repository data, as far as I can tell, means the name of the >> archive, and the location. Do you really mean we are not shipping >> any, say, foo.c file in the sources, just a locatio where you can get >> the foo.c file from, at a particular version? > 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 pout a branch locally does not end up with you downloading the terabytes of stuff in the repo out there. 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, >> > The whole idea of the proposal is to NOT create an export. >> >> If we are not creating and export, and we are only shipping the >> repository data, how come there needs to be a check for uncommitted >> files? If the changes are uncommitted, that means the repo does not >> know about it; and if we only ship the repository data, we are not >> shipping stuff not in the repo. >> >> What am I missing? > They might be uncommitted because the maintainer forgot to commit > them. The only question is whether we should abort, commit the > changes, or ignore the changes. There is no technical problem with > either of these cases. Well, as a developer, I would rather that someone else running dpkg source on a package not try to commit to my repo, since it shall fail. 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. manoj -- DEATH: The penultimate commercial transaction finalized by probate. Bernard Rosenberg 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]