[SVN] - Conflicten in Binary Files

[Verwijderd]

Hier gebruiken we voor het developpen SVN. Dit gaat voor text-based bestanden goed, maar voor binary bestanden (in ons geval DBF-bestanden) ontstaan hier vaak conflicten. We ontwikkelen in Visual FoxPro.

Wij gaan dan meestal handmatig alle conflicten bij langs en verwijderen de huidige dbf, en hernoemen het bestand met het hoogste revisienummer terug (halen dus .Rxx uit de bestandsnaam).

Dit kost veel tijd en we zoeken hiervoor een oplossing. Ik heb op google gezocht naar tools die binary bestanden toch kunnen mergen, in het bijzonder dbf-bestanden. Het lijkt me dat dit niet heel erg lastig is, maar kon niets vinden over dit onderwerp.

Wat raden jullie ons aan? Toch een tooltje schrijven (waarin? geen ervaring mee..) die alle conflicten bij langs gaat en vervolgens het hoogste revisienummer terugzet? Of is er toch ergens een tooltje?

Op GoT kon ik ook niets vinden.

Gebruikte keywords: svn conflicts (dbf OR binary) solve script
etc.

[kenneth]

Ik betwijfel of het simpel is: binaire bestanden hebben toch vaak een aparte indeling, al dan niet in vaste blokken, met checksums, enzovoort.

Hoe komt het dat de conflicten optreden? Kan je niet afspreken dat slechts één persoon tegelijk aan een dbf werkt? Evt. met locking hints.

[Verwijderd]

Het zijn gewoon tabellen. Ook bestanden die door het pakket zelf worden aangepast kunnen het zijn, maar conflicten worden meestal opgelost door de nieuwste revisie terug te zetten. Echter, als bijv. 1 record is toegevoegd aan een tabel zorgt dit ervoor dat je jouw toegevoegde records kwijt bent.

Hoe zou ik een script kunnen maken die alle hoogste revisies terugzet? Daar zouden we al heel blij mee zijn, maar ik heb geen idee waar ik moet beginnen...

Wij hebben nu al de policy dat slechts 1 persoon tabellen aanpast, maar dat gaat soms toch niet helemaal goed.

Thanx voor de snelle reply trouwens!

[The - DDD]

Dit klinkt als een typisch geval waarin locking een uitkomst kan bieden. Latere versies van SVN ondersteunen het locken van files in de repository. Details weet ik zo niet, maar het komt er geloof ik op neer dat je expliciet een file dient te locken, wat dus misgaat als de file al gelocked is.

Geen binary merge, maar ik denk wel een werkwijze die kan helpen. Diegene die vergeet te locken is zelf verantwoordelijk voor de prut waar hij dan in komt. Het moeten locken van een file is afdwingbaar middels een property.

Misschien dat je er wat mee kunt.

http://svnbook.red-bean.c...svn.advanced.locking.html

Handig stukje:

The mechanism is a special property, svn:needs-lock. If the property is attached to a file (the value is irrelevant), then the file will have read-only permissions. When the user locks the file and receives a lock token, the file becomes read-write. When the lock is released—either explicitly unlocked, or released via commit—the file returns to read-only again.

[ Voor 36% gewijzigd door The - DDD op 14-09-2006 13:22 ]

[Verwijderd]

@The-DDD, thanx voor je reply! Dit is voor ons inderdaad een oplossing voor bepaalde bestanden. Probleem is wel dat tijdens het developpen er ongewild onder water binary bestanden worden aangepast door de ontwikkelomgeving. Als 1 user die bestanden zou locken, kan niemand verder ontwikkelen. Lijkt mij ook niet de bedoeling.

Locken is dus voor bepaalde bestanden / dbf's van toepassing, zal het in de groep gooien. Echter, voor de bestanden die onder water worden gewijzigd is het meestal voldoende de nieuwste revisie over je huidige revisie heen te gooien, dus zoals ik al zei de revisie met het hoogste nummer te renamen. Ik heb hier op gezocht, om dit te automatiseren, maar daarover heb ik niets kunnen vinden. Ik zoek dus voor die bestanden iets waarbij automatisch de nieuwste revisie local komt te staan. Zijn een stuk of 10 bestanden en het is nogal overbodig werk om dit elke dag handmatig te doen...

Is dus gewoon een file-rename-script, maar ik ben echt een leek op dat gebied. Iemand een idee?

[Verwijderd]

Niemand die mij een handje kan helpen??

[djc]

We doen niet echt aan script requests hier. Het zou echter niet al te moeilijk moeten zijn: je doorloopt alle directories, zoekt bestanden die in verschillende varianten bestaan (met .rxxx en .ryyy) en geeft degene met het hoogste nummer een naampje. Ga gewoon eens wat knutselen met Python of PHP of Perl of een taal waar jij of iemand in je groep ervaring mee heeft.

[Verwijderd]

Manuzhai schreef op vrijdag 15 september 2006 @ 22:50:
We doen niet echt aan script requests hier. Het zou echter niet al te moeilijk moeten zijn: je doorloopt alle directories, zoekt bestanden die in verschillende varianten bestaan (met .rxxx en .ryyy) en geeft degene met het hoogste nummer een naampje. Ga gewoon eens wat knutselen met Python of PHP of Perl of een taal waar jij of iemand in je groep ervaring mee heeft.

Ik weet dat er niet aan script requests wordt gedaan, maar ik had/heb geen idee hoe ik het op moet lossen, maar dat zal ik wel proberen uit te zoeken Thanx iig.

[The - DDD]

Je kan misschien iets proberen met hook scripts, maar dat is geloof ik server side.

[pgussow]

Waarom heb je die BDF files in je SVN zitten? Is dat wel nodig? De enige reden die ik kan verzinnen om DBF files in SVN te zetten is als je een parameter tabel oid hebt. Voor de rest lijkt het me dat in een DB alleen maar process data zit en geen data die je zou willen meeleveren.

Handiger is denk it dat het DDL-script in SVN zet met eventueel een init.sql met daarin de insert-statements voor de parameters.

[The - DDD]

pgussow schreef op woensdag 20 september 2006 @ 13:48:
Waarom heb je die BDF files in je SVN zitten? Is dat wel nodig? De enige reden die ik kan verzinnen om DBF files in SVN te zetten is als je een parameter tabel oid hebt. Voor de rest lijkt het me dat in een DB alleen maar process data zit en geen data die je zou willen meeleveren.

Handiger is denk it dat het DDL-script in SVN zet met eventueel een init.sql met daarin de insert-statements voor de parameters.

Hmm, in combinatie met een hookscript... Kan leuk zijn...

[Verwijderd]

pgussow schreef op woensdag 20 september 2006 @ 13:48:
Waarom heb je die BDF files in je SVN zitten? Is dat wel nodig? De enige reden die ik kan verzinnen om DBF files in SVN te zetten is als je een parameter tabel oid hebt. Voor de rest lijkt het me dat in een DB alleen maar process data zit en geen data die je zou willen meeleveren.

Handiger is denk it dat het DDL-script in SVN zet met eventueel een init.sql met daarin de insert-statements voor de parameters.

Veel kan ik er niet over zeggen, maar deze DBF's moeten er echt in . Bijv. een DBF met veldnamen + omschrijvingen + tabelnamen van andere tabellen.

Een dergelijke SQL is echt niet te doen, het gaat in dit geval om 40+ dbf's...

Heb in VBScript al een scriptje geschreven die de nieuwste revisie terug zet.