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
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 <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: