Ok before I make myself a complete idiot...
(Which I probably will be doing now)
There are a load of errata in my previous post, more than the usual
answering while doing other things and also being a completely chaotic
personality, induced errors.
I answered shortly after waking up and having a baby boy wanting
attention at the same time. So excuse all the errata I made in my last post.
Besides the usual typos, of course, Git is not a distributed filesystem
(although it comes close to being actually a versioning filesystem)
it is a distributed RCS (Or a complete moron if your are from the UK, it
depends on your location of physical presence).
So my excuses to everyone reading my last technobabble.
Werner
Werner Punz schrieb:
Ah lovely saturday morning and a general technology discussion.
Ok here is the deal, it is a very common practice to use git for local
versioning and svn or cvs for hosting the code (I do that very often).
There are downsides to this practice. First of all git-svn does not have
external parsing. Git has a similar mechanism subprojects but there is
no bridget between git and svn in this regard, you have to symlink for
instance manually to match the externals.
Secondly it is a speed issue as well. Git is a distributed filesystem
which does most operations locally and delegates the server to a storage
system only. Which means you have local branches and local commit
histories (one of the reasons why I use it) but the downside is it
mirrors literally all revisions into you local filesystem (which is not
as bad as it sounds since it stores the revisions very efficiently, way
more than svn does) which means the initial mirror of a bigger project
takes a very long time. And there the apache infrastructure which by far
is not our idea comes into the game, having a read only git mirror
speeds up this process much more swiftly.
As for Andrews argument, this is no bothering from our side, as it seems
the infrastructure people have been working on this for almost a year
now and now have a stable infrastructure and many projects have moved
towards this read only mirror.
The also seem to think about providing the same fo Mercurial in the future.
Werner
Mike Kienenberger schrieb:
I don't know much about git, but I know that other committers on
Apache Cayenne use git to commit to the Cayenne svn, so it's certainly
possible to do what Andrew suggests. From my limited git
understanding, that's the typical practice of using git -- as a
front-end to svn or cvs.
On Fri, May 15, 2009 at 4:08 PM, Andrew Robinson
<andrew.rw.robin...@gmail.com> wrote:
I would say -1. Seems pointless to use another version control client
that is not 100% compatible with SVN when the SVN command-line and UI
clients works fine. What next, a mercurial read-only repository too?
We have chosen to use subversion with MyFaces at Apache, I don't see
any reason to support other clients just to appease some peoples
technology fix. But this is just my opinion.
Note that there are tools out there to do this type of support from
the client, not the server. For example,
http://www.selenic.com/mercurial/wiki/WorkingWithSubversion details
how to use Mercurial as an SVN client and even be able to commit to
SVN! In my opinion, if someone wants to use git, then they should find
a similar tool for git and not burden the folks at Apache.
-Andrew
FYI:
http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn
http://texagon.blogspot.com/2008/02/use-mercurial-you-git.html
http://weblog.masukomi.org/2008/02/07/a-rebuttal-to-use-mercurial-you-git
On Fri, May 15, 2009 at 10:45 AM, Matthias Wessendorf
<mat...@apache.org> wrote:
some more infos:
http://wiki.apache.org/general/GitAtApache
On Fri, May 15, 2009 at 11:39 AM, Matthias Wessendorf
<mat...@apache.org> wrote:
On Fri, May 15, 2009 at 11:37 AM, Werner Punz
<werner.p...@gmail.com> wrote:
Matthias Wessendorf schrieb:
core
Ok, I filed this:
https://issues.apache.org/jira/browse/INFRA-2053
maybe we should also think about making the JSF 1.1.x stuff a
branch ...
(since we already work on 2.0.x....)
+1
1.1.x branch
1.2 trunk
2.0 branch
hehe :-) just wrote a similar email :-)
-Matthias
instead of
1.1 trunk
1.2 trunk_1.2
2.0 branch
this also helps the infrastructure people!
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
