Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [xtext-dev] Xtext migrates to Git! 
hi Dennis,

Comments below

    Now, there are three questions we have to decide:
    1) About the repository structure. Here, we should keep in mind,
    that: Every repository has its own history. Branching and tagging
    is always repository-wide. When you initially want to "download"
    the source code (git clone), only complete repositories can be
    downloaded. Therefore, I propose to have exactly one repository
    with the structure as it currently is in
    http://git.softeys.de/tmf.xtext.git/tree However, I noticed that
    our releng-stuff is in
    http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tmf/org.eclipse.xtext.releng/?root=Modeling_Project
    rather than
    http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tmf/org.eclipse.xtext/releng/?root=Modeling_Project
    Is there a specific reason for having this special
    top-level-folder? Having it in the sub-folder
    "org.eclipse.xtext/releng" would simplify and unify the structure.
That is because during the build we need a posibility to check out the releng project only, without hundreds megabytes of "unnecessary" artifacts. It is also important that releng project don't share the same directory with the rest of bundles (simpler scripts easy cleanup etc.)..
ok, then I guess it's the best to keep the repository structure exactly as it is here: 
http://git.softeys.de/tmf.xtext.git
http://git.softeys.de/tmf.xtext.releng.git
Another option would be sub-modules. However, I'd have to do do some more investigation to see if, and how, this works. 
http://book.git-scm.com/5_submodules.html



    2) Import history vs. import import HEAD only. I propose to import
    HEAD only, since with each "git clone" one has to download the
    repositories complete history which for us is currently 170MB. We
    should have a second, read-only repository containing the complete
    history for the cases we need to do some archeology. I've asked
    the webmaster whether this is possible:
    https://bugs.eclipse.org/bugs/show_bug.cgi?id=317923
Du meinst, in 2-3 Jahren haben wir unsere Geschichte noch einmal deutlich, denn git-Repository wird zu groß? Mit CVS oder SVN auschecken wir nur den aktuellen Stand und die Geschichte kann bei Bedarf abgerufen werden. Ich denke also, mit git es sollte auch möglich sein, zu konfigurieren, wie viel Geschichte meiner Klon enthalten wird.
I didn't say there is anything like "too big". It's more that now is an opportunity for clean up, so let's use it.
However, after some googling I found out that three is actually a way to do a clone with a partial history: 
git clone --depth 10 git://git.eclipse.org/foo.git
This will only import the last 10 revisions. One drawback is that it doesn't work via http, but only git:// and file:// For us, it reduces the size of the local history from 170MB to 67MB. Considering that our working copy currently has a size of 120MB, this is a quite respectable number.
With having this option available, I think there is nothing wrong with importing the complete history. This will make life less complicated for the webmaster and us. 

regards,
 Moritz



Regards,
Dennis.
------------------------------------------------------------------------

_______________________________________________
xtext-dev mailing list
xtext-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/xtext-dev



--
Moritz Eysholdt
Software Architect

Telefon: +49 (0) 431 / 5606-335
Mobile: +49 (0) 179 / 6788196
Telefax: +49 (0) 431 / 5606-339

http://www.itemis.de
moritz.eysholdt@xxxxxxxxx

https://www.xing.com/profile/Moritz_Eysholdt

itemis AG
Schauenburgerstraße 116
24118 Kiel
Germany 
Rechtlicher Hinweis:

Amtsgericht Dortmund, HRB 20621

Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus

Back to the top