From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:39
On 9/3/06, Jon Smirl [off-list ref] wrote:
The Mozilla people have a web page describing what they are looking
for in a new version control system. How does git stack up?
Hi Jon,
you've been playing with GIT quite a bit by now, so I guess you know
the answer ;-) Is there anything in particular you are wondering
about?
The one item that sticks out for me as not there is ACLs, but access
controls can be implemented in hooks for direct pushes. Maintain an
.htaccess-like file and have a perl script to check it on pushes to
the repo.
Oh, and "partial tree pulls for localisers". Perhaps git-cvsserver can
help there? Localisers can just use TortoiseCVS and get a checkout of
the language pack subdir.
cheers,
martin
--
VGER BF report: U 0.544429
From: Jon Smirl <hidden> Date: 2016-06-15 22:42:39
On 9/2/06, Martin Langhoff [off-list ref] wrote:
On 9/3/06, Jon Smirl [off-list ref] wrote:
quoted
The Mozilla people have a web page describing what they are looking
for in a new version control system. How does git stack up?
Hi Jon,
you've been playing with GIT quite a bit by now, so I guess you know
the answer ;-) Is there anything in particular you are wondering
about?
Shallow clones are a big problem. We have Mozilla down to 450MB is
git, but that is still gigantic for anyone doing an initial check out,
especially if they don't have good broadband. It is over 10x the data
that CVS brings down. Even without doing shallow clones git still
needs to be modified to restart an interrupted pack transfer.
The one item that sticks out for me as not there is ACLs, but access
controls can be implemented in hooks for direct pushes. Maintain an
.htaccess-like file and have a perl script to check it on pushes to
the repo.
I don't see ACLs as that big an issue. If you convert to model where
everyone has their own repo and you just push changesets at each
other, ACLs are much less important. You need ACLs when 2,000 people
have commit privs.
Oh, and "partial tree pulls for localisers". Perhaps git-cvsserver can
help there? Localisers can just use TortoiseCVS and get a checkout of
the language pack subdir.
Partial repo pulls and an issue to. The mozilla repo has much more
than a browser in it, it also has a large mail/news program. A partial
repo pull may not be what is needed for git, instead git needs a
partial repo checkout.
--
Jon Smirl
jonsmirl@gmail.com
--
VGER BF report: U 0.827771
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:39
Jon Smirl wrote:
quoted
Oh, and "partial tree pulls for localisers". Perhaps git-cvsserver can
help there? Localisers can just use TortoiseCVS and get a checkout of
the language pack subdir.
Partial repo pulls and an issue to. The mozilla repo has much more
than a browser in it, it also has a large mail/news program. A partial
repo pull may not be what is needed for git, instead git needs a
partial repo checkout.
Or better support for subprojects.
I think you can fake subproject support using separate repositories
for subprojects, in the directory matching the one in the whole project,
and the project repository, where we pull/push subprojects into.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
--
VGER BF report: U 0.877495
From: Jon Smirl <hidden> Date: 2016-06-15 22:42:39
On 9/3/06, Jakub Narebski [off-list ref] wrote:
Jon Smirl wrote:
quoted
quoted
Oh, and "partial tree pulls for localisers". Perhaps git-cvsserver can
help there? Localisers can just use TortoiseCVS and get a checkout of
the language pack subdir.
Partial repo pulls and an issue to. The mozilla repo has much more
than a browser in it, it also has a large mail/news program. A partial
repo pull may not be what is needed for git, instead git needs a
partial repo checkout.
Or better support for subprojects.
I think you can fake subproject support using separate repositories
for subprojects, in the directory matching the one in the whole project,
and the project repository, where we pull/push subprojects into.
You can't really fake it. Many of the projects in Mozilla are
dependent on each other. If you break them up into separate
repositories you lose the ability to do a cross project commit. This
is common when you are changing an interface between the subprojects.
Would it make sense for git to treat a tree of projects like you
describe as a single entity? So a commit would transparently commit to
all of the subprojects. Maybe the commit entry's sha1 could be set up
so that it would be identical in all subprojects. That would let you
string them back together.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
--
VGER BF report: U 0.877495
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jon Smirl
jonsmirl@gmail.com
--
VGER BF report: S 0.995201
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:39
On 03-09-2006 15:46, Jon Smirl wrote:
On 9/3/06, Jakub Narebski [off-list ref] wrote:
quoted
Jon Smirl wrote:
quoted
quoted
Oh, and "partial tree pulls for localisers". Perhaps git-cvsserver can
help there? Localisers can just use TortoiseCVS and get a checkout of
the language pack subdir.
Partial repo pulls and an issue to. The mozilla repo has much more
than a browser in it, it also has a large mail/news program. A partial
repo pull may not be what is needed for git, instead git needs a
partial repo checkout.
Or better support for subprojects.
I think you can fake subproject support using separate repositories
for subprojects, in the directory matching the one in the whole project,
and the project repository, where we pull/push subprojects into.
You can't really fake it. Many of the projects in Mozilla are
dependent on each other. If you break them up into separate
repositories you lose the ability to do a cross project commit. This
is common when you are changing an interface between the subprojects.
Would it make sense for git to treat a tree of projects like you
describe as a single entity? So a commit would transparently commit to
all of the subprojects. Maybe the commit entry's sha1 could be set up
so that it would be identical in all subprojects. That would let you
string them back together.
Scratch that. You can fake subproject support using something similar
to the way Junio works with TODO branch. Namely, separate repositories
for subprojects, each as if it would start from it's own directory
(although you can manage without that, it only would be slightly harder
to set it up), and main repository working directory composed from
subproject repositories checked out to correct place. Add to this
ingnoring object database (i.e. .git repositories), and you have whole
repository... where you can do whole repository commits to.
E.g. the following directory structure
main-project/
main-project/.git
main-project/subproject/
main-project/subproject/.git
main-project/subproject/...subproject files...
where second .git is in .gitignore or info/excludes, but the subrpoject/
directory itself isn't.
If this is not enough, check out ideas in Subpro.txt in the 'todo' branch
in git repository. It adds additional 'bind' header... the implementation
(search for 'gitlink') were if I remember correctly never fully implemented
and is not in git, although parts of it like git-read-tree and
git-write-tree --prefix option made it.
http://www.kernel.org/git/?p=git/git.git;a=blob;f=Subpro.txt;hb=todo
As commit id depends on the contents, including _parents_ and _tree_,
it is I think impossible to set commit entry sha1 to be identical.
P.S. I just hope that it would pass VGER filter. I don't have much luck
with it lately...
--
Jakub Narebski
Poland
--
VGER BF report: S 0.994192
From: Martin Langhoff <hidden> Date: 2016-06-15 22:42:39
On 9/4/06, Jon Smirl [off-list ref] wrote:
You can't really fake it. Many of the projects in Mozilla are
dependent on each other. If you break them up into separate
repositories you lose the ability to do a cross project commit. This
is common when you are changing an interface between the subprojects.
In many projects this is handled by having tags and generally
versioning modules and interfaces. Being independent gives the
subprojects/modules a lot more freedom to work/branch on wild
tangents, and the versioned interfaces mean that -- with the
contraints of the versioned interfaces -- you can mix and match
branches/releases of the different subprojects.
In short, I'd definitely break those up :-)
cheers,
martin
--
VGER BF report: U 0.513231
From: Jon Smirl <hidden> Date: 2016-06-15 22:42:39
On 9/3/06, Martin Langhoff [off-list ref] wrote:
On 9/4/06, Jon Smirl [off-list ref] wrote:
quoted
You can't really fake it. Many of the projects in Mozilla are
dependent on each other. If you break them up into separate
repositories you lose the ability to do a cross project commit. This
is common when you are changing an interface between the subprojects.
In many projects this is handled by having tags and generally
versioning modules and interfaces. Being independent gives the
subprojects/modules a lot more freedom to work/branch on wild
tangents, and the versioned interfaces mean that -- with the
contraints of the versioned interfaces -- you can mix and match
branches/releases of the different subprojects.
In short, I'd definitely break those up :-)
Mozilla always ships as a complete system so there is no need to deal
with old versions of the pieces. Only the external interfaces are
frozen and versioned. This is similar to the Linux kernel. The user
space API is frozen, but when an internal device driver interface
changes all of the drivers in the kernel tree get updated in lock
step. Doing it this way removes a lot of overhead in maintaining
binary compatibility.
--
Jon Smirl
jonsmirl@gmail.com
--
VGER BF report: U 0.502564