Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, 7 Oct 2007 22:04:21 +0200, Frank Lichtenheld <djpig@debian.org> 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
>> <djpig@debian.org> 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 <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: