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

Re: [PATCH] proposed v3 source format using .git.tar.gz

On Mon, 8 Oct 2007 02:55:37 +0200, Frank Lichtenheld <djpig@debian.org> 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
>> <djpig@debian.org> 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

        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

        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.

You never hesitate to tackle the most difficult problems.
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: