compilteroptionen getIt

[himitsu]

Explorer > leeres Verzeichnis erstellen > TortoiseSvn > create repository here
das Selbe geht auch mit TortoiseGit (als Bare-Repo erstellen) ... bei uns mal genutzt, um auf einem Share ein lokales Repo für Alle zu haben, weil es zu groß für GitHub war

und dann in anderem Verzeichnis den file://-Pfad (welchen man beim Erstellen angezeigt bekommt) beim Checkout benutzen

Bei GitHub kann man auch mit SVN auschecken (GitHub hat bei sich was eingebaut)
oder andersrum kann man auch mit GIT bei einem SVN-Server auschecken/clonen (GIT hat da was eingebaut)
und dann lokal mit dem Anderen arbeiten, als wie der Server ist.
(pervers wird es nur, wenn man mit Git bei der Svn-Bridge von GitHub sich einen runterholt)

[Uwe Raabe]

Zitat:

Zitat von TurboMagic (Beitrag 1509549)

SVN dürfte für den Anfang einfacher zu verstehen sein.

Das höre ich aber immer nur von Leuten die schon mit SVN arbeiten oder bis vor nicht allzu langer Zeit gearbeitet haben. Jede Umstellung ist erstmal ein Umstieg auf etwas anderes. Einen Einstieg in SVN als Vorbereitung für einen späteren Einsatz von Git halte ich eher für kontraproduktiv.

Da man sich gerade als Anfänger mit der Konsole manchmal etwas schwer tut, hängt die Akzeptanz in hohem Maße von der verwendeten GUI ab. Mein persönlicher Favorit ist da schon seit einer Weile (und vielen Fehlversuchen mit Alternativen):Fork

[himitsu]

Beim Merge geht Einiges mit Git besser, aber Anderes wird schlimmer.

Aber gerade wenn im Git mal was quer steht, dann wird es schlimm, weil Git einfach so viel kann, dass das nichtmal die Profis mit 200 Jahren Erfahrung sich noch auskennen.
Außerdem ist es bei SVN unmöglich die Historie zu zerstören. Was einmal eingecheckt ist, dass bleibt auch drin, während man in GIT ALLES vernichten kann, wenn man will oder zu doof rumklickt.


Also ja, SVN ist einfacher, auch wenn Git schon ein paar Vorteile hat.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1509554)

Also ja, SVN ist einfacher

Aus den Argumenten kann man allenfalls folgern, dass SVN sicherer gegen Fehlbedienung ist als Git. Aber auch das ist eher eine Frage der GUI und deren intuitiven Bedienung.

Zitat:

Zitat von himitsu (Beitrag 1509554)

Aber gerade wenn im Git mal was quer steht, dann wird es schlimm, weil Git einfach so viel kann, dass das nichtmal die Profis mit 200 Jahren Erfahrung sich noch auskennen.

Das fällt meiner Meinung nach eher in den Bereich der Urban Myths und wird ebenfalls gern von SVN-Anwendern als Umstiegsverhinderungsargument verwendet.

[himitsu]

Zumindestens hatten wir es mehrmals geschafft, dass garnichts mehr ging und brauchten dann 'ne Weile, um eine passende Lösung zu googlen.
Teilweise bestand die Lösung dann darin das lokale Repo zu löschen und neu zu clonen.

Natürlich kann man sowohl in SVN, als auch Git viel mist bauen,
aber standardmäßig gibt es keinen Weg, um einmal committetes zu löschen, also lässt sich immer Alles wiederherstellen (außer Backup, die Historie umschreiben und Restore des Servers)

In Git kannst mit einem Force-Push alles auf dem Server löschen/überschreiben. (wobei im TortoiseGit die Checkbox für Force fehlt und man es über die Console machen muß ... z.B. wenn man den/die letzten Commits löschen will)
Das Einzige, was man bei SVN standardmäßig nachträglich ändern kann, ist die Commit-Message.

Aber ja, genauso wie im SVN, kann man im Git durch Hooks so Einiges verbieten.

[rwb]

Moin Himitsu,

>Es knallt sofort, wenn "irgendwas" dort gewählt ist.
Du hast vollkommen recht. Das war auch das Resultat meiner Versuche. Vielleicht kannst Du mir zu folgende Fragen etwas sagen. Wofür besteht diese Seite mit den Getit-Optionen? Was ist ihr Vorteil wenn sie angekreuzt sind.? Was sind die Konsequenzen für mich wenn ich alle abgewählt habe? Hat das zum Beispiel Einfluß auf meine Benutzung von JEDI Komponenten?

Danke
Rolf

Zitat:

Zitat von himitsu (Beitrag 1509545)

Zitat:

Zitat von rwb (Beitrag 1509538)

Ich werde jetzt versuchen herauszufinden, welche Abhängigkeit die Ursache war.

Nicht nötig.

Es knallt sofort, wenn "irgendwas" dort gewählt ist.




Es gibt auch ein TortoiseGit. (und TortoiseHG)

Für echte Git-Freaks ist das zwar pervers, weil man dort versucht hat die Git-Terminologie auf SVN umzubiegen,
aber dafür ist die Grundfunktion von Git nutzbar und aus Sicht von TortoiseSvn leicht verständlich.

Nur dass man nicht den Push vergessen sollte, vergisst man manchmal.
Commits sind erstmal nur Lokal und spiegeln sich nicht ungedingt sofort auf dem Server wieder (falls/wenn man Einen nutz).


Und ja, auch SVN kann man lokal nutzen, also ein lokales Verzeichnis genauso nutzen, wie einen SVN-Server.
Und dann könnte man zwischen auch zwei "Servern" die Daten synchronisieren/austauschen.

[himitsu]

Genau getestet hatte ich es nicht, aber im Prinzip, wird hier beim Öffnen des Projektes entweder ein automatischer Download angestoßen (hoffe/glaube ich nicht), oder zumindestens eine Warnung ausgegeben, dass für dieses Projekt die Instalation von gewissen GetIt-Packages nötig sei, eventuell/vermutlich mit dem direkten Angebot sie zu installieren.
(da man nur installierte Packages dort auswählen kann, würde ich es so vermuten)

Was ich mich eher noch frage ist, wie es bei Updates/Upgrades aussieht
* ist die Versionnummer im Namen enthalten? (knallt es, wenn diese Version/Name nicht mehr existiert und eine andere Version/Name ist installiert oder noch nicht)
* und wie sieht es aus, wenn man auf die nächste Delphi-Version upgradet, bzw. das Projekt dort öffnet
* und wie sieht es z.B. mit JEDI, Indy und Co. aus, was man alternativ zu GetIt auch selber installiert haben könnte

[mmw]

Hallo,

wenn man z.B. ein Project von 10.3.3 in 10.4.2 öffnet, kommt ein Dialog

mit der Frage ob die fehlende Abhängigkeit installiert werden soll oder nicht.

Wenn man auf installieren klickt, würde man ja vermuten das es installiert wird,
wird's aber nicht.

Als Status erscheint dann 'unavaible' bei den GetIt - Abhängigkeiten.

Man muss es dann manuell über GetIt installieren

Unter GetIt -Abhängigkeiten werden nur die über GetIt -installierten Sachen
angezeigt.


Gruß

[himitsu]

Also scheinbar genauso krank, wie im GetItCmd.

neues Delphi -> neues GetIt -> neue Package-Versionen ... blöd nur, dass die Versionsnummer im Namen steht und es dann knallt, wenn diese Version nicht mehr verfügbar ist.

[TurboMagic]

Wie schon geschrieben ist das buggy. Wenn es funktionieren würde
könnte man beim öffnen eines Projektes ggf. fehlende GetIt Pakete
nachinstallieren...