[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

        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.

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: