Dateirechte vor SVN-Import sichern
Dateirechte vor SVN-Import sichern
Hallo zusammen,
bei einem mittels SVN-Repository gesicherten Projekt möchte ich Files darin sichern, bei dennen die Dateirechte erhalten bleiben sollen. Nach einem checkout sollen somit immer definierte Dateiattribute gesetzt sein, sowie die Eigentümer und die Gruppe der Datei erhalten bleiben.
Gibt es für diese Art von Problem bereits eine Lösung?
Meine Alternative sieht aktuell so aus, dass ich ein Script erstelle, welches alle Fileattribute recursiv ausliest und in eine Textdatei sichert. Diese Textfile wird nach einem checkout von einem Scritpt wiederrum abgearbeitet und die Fileattribute gesetzt.
Gibt es denn für diese Alternative evtl. bereits ein Programm, etc.?!?
Gruß und Danke,
choji
bei einem mittels SVN-Repository gesicherten Projekt möchte ich Files darin sichern, bei dennen die Dateirechte erhalten bleiben sollen. Nach einem checkout sollen somit immer definierte Dateiattribute gesetzt sein, sowie die Eigentümer und die Gruppe der Datei erhalten bleiben.
Gibt es für diese Art von Problem bereits eine Lösung?
Meine Alternative sieht aktuell so aus, dass ich ein Script erstelle, welches alle Fileattribute recursiv ausliest und in eine Textdatei sichert. Diese Textfile wird nach einem checkout von einem Scritpt wiederrum abgearbeitet und die Fileattribute gesetzt.
Gibt es denn für diese Alternative evtl. bereits ein Programm, etc.?!?
Gruß und Danke,
choji
Google brachte [1] zu tage. Es scheint also noch nichts fertiges zu geben, man könnte aber die Permissions als Properties [2] setzen und diese dann auf Clientseite auslesen und setzen. Das das nicht fest in Subversion drin ist ist verständlich, das nicht die verschiedenen OS das ja recht unterschiedlich umsetzen.
[1] http://www.abridgegame.org/pipermail/da ... 02536.html
[2] http://svnbook.red-bean.com/nightly/en/ ... props.html
Gruß Bert
[1] http://www.abridgegame.org/pipermail/da ... 02536.html
[2] http://svnbook.red-bean.com/nightly/en/ ... props.html
Gruß Bert
Programmer: A biological machine designed to convert caffeine into code.
xmpp:bert@debianforum.de
xmpp:bert@debianforum.de
- meandtheshell
- Beiträge: 4054
- Registriert: 14.01.2005 17:51:30
hm ... Ich bin mir nicht ganz klar ob ich Dich richtig verstanden habe.
Wenn es aber nur darum geht Datei Rechte usw. wie sie auf POSIX Systemen definiert sind von einer Maschine A zu einer Maschine B mitzunehmen dann machst Du ganz einfach einen
- dump von dem original repository und
- spielst diesen dort wo Du es haben willst weider ein http://svnbook.red-bean.com/nightly/en/ ... nt.migrate
Reden wir von derselben Sache - nein?
markus
Wenn es aber nur darum geht Datei Rechte usw. wie sie auf POSIX Systemen definiert sind von einer Maschine A zu einer Maschine B mitzunehmen dann machst Du ganz einfach einen
- dump von dem original repository und
- spielst diesen dort wo Du es haben willst weider ein http://svnbook.red-bean.com/nightly/en/ ... nt.migrate
Reden wir von derselben Sache - nein?
markus
Nö, damit würdest Du ja das gesammte Repository austauschen. Ich hab das so verstanden, das er nach einem Checkput die Dateirechte der Dateien in der Workingcopy anpasst.
Gruß Bert
Gruß Bert
Programmer: A biological machine designed to convert caffeine into code.
xmpp:bert@debianforum.de
xmpp:bert@debianforum.de
- meandtheshell
- Beiträge: 4054
- Registriert: 14.01.2005 17:51:30
hallo Bert
Ok gut möglich das Du Recht hast, aber selbst wenn es so ist wie Du es verstanden hast und nicht so wie ich es verstanden habe kann er immer filtern - also so oder so geht das. http://svnbook.red-bean.com/nightly/en/ ... dumpfilter
@choji
Wie Du siehst sind wir uns nicht sicher was Sache ist - hilf uns ...
Hm ... im Thread Titel steht dann noch etwas von " ... vor SVN Import". Das sagt mir man möchte nicht von einem repo in eine wc auschecken sondern nicht versionierte Daten in ein repo schieben.
FAZIT
Ich bin verwirrt
markus
Ok gut möglich das Du Recht hast, aber selbst wenn es so ist wie Du es verstanden hast und nicht so wie ich es verstanden habe kann er immer filtern - also so oder so geht das. http://svnbook.red-bean.com/nightly/en/ ... dumpfilter
@choji
Wie Du siehst sind wir uns nicht sicher was Sache ist - hilf uns ...
Hm ... im Thread Titel steht dann noch etwas von " ... vor SVN Import". Das sagt mir man möchte nicht von einem repo in eine wc auschecken sondern nicht versionierte Daten in ein repo schieben.
FAZIT
Ich bin verwirrt
markus
Das kommt mir auch so vor...
Er hat doch eigentlich recht klar geschrieben:
- er macht einen Import
- die Rechte der Dateien vor dem Import sollen im Repository gehalten werden
- nach einem Checkout sollen die Rechte im Arbeitsverzeichniss wieder so wie vor dem Import sein.
Mit Dumpfilter hat das nichts zu tun. Man kann sicher sich jetzt über alle möglichen Spielerein im Subversion unterhalten, aber wir wollen doch lieber bei der Sache bleiben?
Gruß Bert
Er hat doch eigentlich recht klar geschrieben:
- er macht einen Import
- die Rechte der Dateien vor dem Import sollen im Repository gehalten werden
- nach einem Checkout sollen die Rechte im Arbeitsverzeichniss wieder so wie vor dem Import sein.
Mit Dumpfilter hat das nichts zu tun. Man kann sicher sich jetzt über alle möglichen Spielerein im Subversion unterhalten, aber wir wollen doch lieber bei der Sache bleiben?
Gruß Bert
Programmer: A biological machine designed to convert caffeine into code.
xmpp:bert@debianforum.de
xmpp:bert@debianforum.de
- meandtheshell
- Beiträge: 4054
- Registriert: 14.01.2005 17:51:30
Ja - die Auflistung der drei Punkte von Dir habe ich auch so verstanden und füge hinzu:
- wenn er Files in das repo importiert sind die Rechte vorhanden
- bei einem checkout einer wc dann ebenso in der wc
- wenn er nun einen checkout macht dann hat er entweder sowieso die Fileattribute wie Sie vorher waren wenn Sie nicht verändert worden sind oder
- er muss mittels hook script immer veranlassen das diese _richtig_ gesetzt werden bei jedem commit oder
- ich mache das mit svndumpfilter beim sichern oder beim restore
Ich warte jetzt bis er noch etwas dazu sagt.
markus
- wenn er Files in das repo importiert sind die Rechte vorhanden
- bei einem checkout einer wc dann ebenso in der wc
- wenn er nun einen checkout macht dann hat er entweder sowieso die Fileattribute wie Sie vorher waren wenn Sie nicht verändert worden sind oder
- er muss mittels hook script immer veranlassen das diese _richtig_ gesetzt werden bei jedem commit oder
- ich mache das mit svndumpfilter beim sichern oder beim restore
Ich warte jetzt bis er noch etwas dazu sagt.
markus
Ich weiß ja das Du gerne sprichst/schreibst. Aber wie hat Tommiboy [1] so schön in seiner Signatur stehen:
"Am liebsten spreche ich von nichts, denn das ist das einzige, wovon ich wirklich etwas verstehe".
O.Wilde
[1] http://www.debianforum.de/forum/viewtop ... 136#444136
Ich will eigentlich nicht persönlich werden, aber Leute die zu allem was zu sagen haben gehen mir einfach gewaltig auf den Nerv.
So, und nun harren wir des OP und können ihm vielleicht auch noch helfen.
Bert
"Am liebsten spreche ich von nichts, denn das ist das einzige, wovon ich wirklich etwas verstehe".
O.Wilde
[1] http://www.debianforum.de/forum/viewtop ... 136#444136
Eben getestet, da die Dateien ja nicht als Fileobjekt direkt vorhanden sind, läßt sich dies schlecht behaupten/wiederlegen.meandtheshell hat geschrieben:Ja - die Auflistung der drei Punkte von Dir habe ich auch so verstanden und füge hinzu:
- wenn er Files in das repo importiert sind die Rechte vorhanden
Nö, die haben immer '-rw-r--r--' Egal was die vor dem Import hatten.meandtheshell hat geschrieben: - bei einem checkout einer wc dann ebenso in der wc
Nein, nach einem checkout (Du meinst sicher ein update, aber wir wissen ja was Du meinst) ist das Attribut wieder auf '-rw-r--r--' , egal was Du vorher in der Workingcopy hattest. Habs eben getestet.meandtheshell hat geschrieben: - wenn er nun einen checkout macht dann hat er entweder sowieso die Fileattribute wie Sie vorher waren wenn Sie nicht verändert worden sind oder
Wenn Du mir jetzt verräts, wie der Hookscript auf dem Server die Attribute auf dem Client setzt, dann steht dem nichts mehr im Wege.meandtheshell hat geschrieben: - er muss mittels hook script immer veranlassen das diese _richtig_ gesetzt werden bei jedem commit oder
Ich wiederhole: das manipuliert das Repository, nicht den Client...meandtheshell hat geschrieben: - ich mache das mit svndumpfilter beim sichern oder beim restore
Ich will eigentlich nicht persönlich werden, aber Leute die zu allem was zu sagen haben gehen mir einfach gewaltig auf den Nerv.
So, und nun harren wir des OP und können ihm vielleicht auch noch helfen.
Bert
Programmer: A biological machine designed to convert caffeine into code.
xmpp:bert@debianforum.de
xmpp:bert@debianforum.de
- meandtheshell
- Beiträge: 4054
- Registriert: 14.01.2005 17:51:30
Hallo Bert,
nur noch kurz weil ich nicht möchte das mich jemand als inkompetenten Menschen hinstellt und weil ich denke das ich manchmal mißverstanden werde und weil ich von Chemnitz weiß das wir beide das besser können.
Was ich sagte geht und ist fachlich vollkommen ok - ob Du folgendes kennst weiß ich nicht - nun auf jeden Fall:
http://fsvs.tigris.org/
http://svn.collab.net/repos/svn/trunk/c ... -side/asvn
Zwei verschiedene Möglichkeiten die Sache zu lösen - eines davon wie ich sagte ein Hook script.
BTW - ich war für ca. 5 Monate im Jahr 2003 SVN Core Developer - solle es also sonst noch speziellere Fragen geben kann man mich fragen aber bitte ohne unterschwelligen Ton den das dient der Sache nicht.
Markus (nicht böse sein wenn ich nicht mehr in dieses Thread poste )
nur noch kurz weil ich nicht möchte das mich jemand als inkompetenten Menschen hinstellt und weil ich denke das ich manchmal mißverstanden werde und weil ich von Chemnitz weiß das wir beide das besser können.
Was ich sagte geht und ist fachlich vollkommen ok - ob Du folgendes kennst weiß ich nicht - nun auf jeden Fall:
http://fsvs.tigris.org/
http://svn.collab.net/repos/svn/trunk/c ... -side/asvn
Zwei verschiedene Möglichkeiten die Sache zu lösen - eines davon wie ich sagte ein Hook script.
BTW - ich war für ca. 5 Monate im Jahr 2003 SVN Core Developer - solle es also sonst noch speziellere Fragen geben kann man mich fragen aber bitte ohne unterschwelligen Ton den das dient der Sache nicht.
Markus (nicht böse sein wenn ich nicht mehr in dieses Thread poste )
Tut mir leid. Ich bin heut in Haarspalter-Modus. Aber keins davon ist ein Hookscript. Das asvn ist ein Clientseitiger (steht ja sogar in der URL) Wrapper um das eigentliche svn Kommando, das (neben ein paar mehr Sachen) genau das macht was ich im 1. Post erwähnte: Die Rechte in den Properties einlagern (commit) und beim Rausholen (update) wieder aus den Properies lesen und setzten.
Insofern könnte das asvn Recht genau da sein was gesucht wurde.
FSVS ist ja eher ein Ersatz für Subversion..
Beide Lösungen haben den Nachteil, das man dann nicht mehr die liebgewordenen Tools / IDEs einsetzen kann.
Auch wenn Du es nicht gerne hörst, aber in Deinen anderen Post hast Du leider Sachen erzählt, die eben so nicht stimmen oder funktionieren.
Gruß Bert
Insofern könnte das asvn Recht genau da sein was gesucht wurde.
FSVS ist ja eher ein Ersatz für Subversion..
Beide Lösungen haben den Nachteil, das man dann nicht mehr die liebgewordenen Tools / IDEs einsetzen kann.
Auch wenn Du es nicht gerne hörst, aber in Deinen anderen Post hast Du leider Sachen erzählt, die eben so nicht stimmen oder funktionieren.
Gruß Bert
Programmer: A biological machine designed to convert caffeine into code.
xmpp:bert@debianforum.de
xmpp:bert@debianforum.de
- meandtheshell
- Beiträge: 4054
- Registriert: 14.01.2005 17:51:30
Was soll ich schreiben:
A: Ja Du hast Recht
oder
B: Das scipt kann auch am Server laufen, fsvs ist kein svn ersatz und (kann nur über emacs reden) kann so konfigurieren das ich zugreifen kann
oder
C: Ich bin ein Mensch, auch ich mache Fehler
oder
D: Meine Stimmung ist am Nullpunkt
oder
E: ...
IMHO ist die Frage beantwortet. Stimmen wir wenigsten hier überein, dass der Thread doch nicht umsonst war?
Noch ein nützlicher Link
http://pixel.global-banlist.de./svn/permissions
markus
A: Ja Du hast Recht
oder
B: Das scipt kann auch am Server laufen, fsvs ist kein svn ersatz und (kann nur über emacs reden) kann so konfigurieren das ich zugreifen kann
oder
C: Ich bin ein Mensch, auch ich mache Fehler
oder
D: Meine Stimmung ist am Nullpunkt
oder
E: ...
IMHO ist die Frage beantwortet. Stimmen wir wenigsten hier überein, dass der Thread doch nicht umsonst war?
Noch ein nützlicher Link
http://pixel.global-banlist.de./svn/permissions
markus
Hallo wieder,
um eurer Diskusion ein Ende zu liefern, hier zuallererst mal die Auflösung zu meiner Fragenstellung:
Eigentlich hatte ich genau Berts Gedankengang. Ich will also sicherstellen, das wer auch immer, den Teil des Projektes auf seinem Linux-Rechner auscheckt die selben Dateirechte/-attribute hat wie Ursrünglich commitet.
Nun ok ich sehe ein das dies nicht der Sinn von SVN ist, da dieses nicht betriebssystemspeziefisch sein sollte.
Zu meiner Lösung nun:
Ich greife Berts Tip zu den Properties auf und bastle ein kleines Skript, dass vor dem commiten bei allen Datein ein Propertie mit deren Rechte anlegt bzw. bei bedarf anpasst.
Beim checkout gibts n kleines Skript für den Weg entgegen.
Großen Dank für eure Hilfe
choji
um eurer Diskusion ein Ende zu liefern, hier zuallererst mal die Auflösung zu meiner Fragenstellung:
Eigentlich hatte ich genau Berts Gedankengang. Ich will also sicherstellen, das wer auch immer, den Teil des Projektes auf seinem Linux-Rechner auscheckt die selben Dateirechte/-attribute hat wie Ursrünglich commitet.
Nun ok ich sehe ein das dies nicht der Sinn von SVN ist, da dieses nicht betriebssystemspeziefisch sein sollte.
Zu meiner Lösung nun:
Ich greife Berts Tip zu den Properties auf und bastle ein kleines Skript, dass vor dem commiten bei allen Datein ein Propertie mit deren Rechte anlegt bzw. bei bedarf anpasst.
Beim checkout gibts n kleines Skript für den Weg entgegen.
Großen Dank für eure Hilfe
choji