Refactoring van code en subversion

[Standeman]

Ik wil een stuk code gaan refactoren. Classes hernoemen, relaties tussen clases wijzigen, etc. Nu heeft mijn IDE daar hele leuke tools voor. Alleen wanneer ik een class hernoem raak ik de history van de file kwijt aangezien subversion, of in iedergeval de svn plugin in Netbeans het niet ziet als een rename, maar als een delete / create bij wijze van spreken.

Nu kan ik ook gewoon de file via svn move hernoemen (of via Tortoise), maar dan moet ik nog handmatig alle referenties naar die class toe handmatig gaan wijzigen. Aangezien ik vrij lui ben, heb ik hier niet zo gek veel zin in

Is er een handige strategie om dit soort zaken aan te pakken of misschien een svn plugin welke wel refactoring ondersteund?

[Niemand_Anders]

Ik gebruik dan geen netbeans, maar mijn SVN plugin voor Visual Studio (VisualSVN) voert de wijziging zowel in het project door als in SVN.

Je kunt natuurlijk wel je class zelf hernoemen, alleen moet je ervoor zorgen dat de bestandsnaam zelf niet wordt aangepast. Ik neem aan dat als je zelf via de IDE een naam wijzigd dat deze wel netjes in SVN wordt doorgevoerd?

Wel apart trouwens dat een refactor tool blijkbaar bestandsnamen wijzigd buiten de IDE zelf om, want anders had de plugin de wijziging wel kunnen oppakken.. Ik ga er blindelings vanuit dat je de laatste versie van de plugin hebt.

[Voutloos]

Refactor tool gebruiken, inhoud hernoemde file kopieren, hernoemde file revert, zelf hernoemen, inhoud @ file plakken.

[JayVee]

Standeman schreef op dinsdag 05 mei 2009 @ 10:44:Alleen wanneer ik een class hernoem raak ik de history van de file kwijt aangezien subversion, of in iedergeval de svn plugin in Netbeans het niet ziet als een rename, maar als een delete / create bij wijze van spreken.

Weet je zeker dat het niet goed gaat? Subversion ondersteund namelijk renames ook niet echt, wat er gebeurd is dat het bestand wordt verwijderd en een "nieuw" bestand wordt aangemaakt, met een extra history, kijk maar:

code:

}$ svn mv index.php hoi
A         hoi
D         index.php
$ svn stat
A  +   hoi
D      index.php

Die + bij hoi staat voor:

code:

Fourth column: Scheduled commit will contain addition-with-history
      ' ' no history scheduled with commit
      '+' history scheduled with commit

[Bl4ckviper]

Je hebt je geschiedenis toch gewoon alsnog SVN verwijderd de bestanden niet echt. Als je je revision number weet kan je het altijd nog terug vinden.

Mocht je dat niet weten zijn er nog andere truckjes.

http://m0j0.wordpress.com...s-from-an-svn-repository/

[ Voor 13% gewijzigd door Bl4ckviper op 05-05-2009 11:19 ]

[Remus]

Bl4ckviper schreef op dinsdag 05 mei 2009 @ 11:18:
Je hebt je geschiedenis toch gewoon alsnog SVN verwijderd de bestanden niet echt. Als je je revision number weet kan je het altijd nog terug vinden.

Mocht je dat niet weten zijn er nog andere truckjes.

http://m0j0.wordpress.com...s-from-an-svn-repository/

Maar als je een rename (eigenlijk move) doet via Subversion, wat iig onder Eclipse volgens mij goed gaat, zowel met Subversive als met Subclipse, dan kan je bij het 'nieuwe' (hernoemde of verplaatste) bestand gewoon de history van het oorspronkelijke bestand terug zien, daarvoor hoef je dus niet op zoek te gaan naar je oude bestand.

Wat dat betreft ben ik niet echt onder de indruk van de Subversion integratie onder Netbeans, voor mijn gevoel werkt het onder Eclipse iig veel beter.

[Standeman]

JayVee schreef op dinsdag 05 mei 2009 @ 11:16:
[...]

Weet je zeker dat het niet goed gaat? Subversion ondersteund namelijk renames ook niet echt, wat er gebeurd is dat het bestand wordt verwijderd en een "nieuw" bestand wordt aangemaakt, met een extra history, kijk maar:

code:

}$ svn mv index.php hoi
A         hoi
D         index.php
$ svn stat
A  +   hoi
D      index.php

Die + bij hoi staat voor:

code:

Fourth column: Scheduled commit will contain addition-with-history
      ' ' no history scheduled with commit
      '+' history scheduled with commit

Hey, je hebt gelijk. Wanneer ik een bestand hernoem zie ik gewoon nog het originele bestand. Ik snap even niet meer hoe ik er nou aan kwam dat het niet zo zou zijn .

Nou ik toch bezig ben, kan ik gelijk even mijn eigen topic kapen. Heeft iemand een manier gevonden om een bestand (incl. history) van 1 repository naar de andere te moven?

[NetForce1]

je kunt een dump filteren met de standaard tools op de server, alleen dat kan lang gaan duren bij grote repositories

[Soultaker]

JayVee schreef op dinsdag 05 mei 2009 @ 11:16:
Weet je zeker dat het niet goed gaat? Subversion ondersteund namelijk renames ook niet echt, wat er gebeurd is dat het bestand wordt verwijderd en een "nieuw" bestand wordt aangemaakt, met een extra history

Dan blijft het probleem toch bestaan, maar wordt de vraag gewoon: hoe zorg ik ervoor dat het hernoemde bestand de geschiedenis van het origineel meekrijgt? Zelfde probleem lijkt me.

Ik zou waarschijnlijk eerst alle bestanden refactoren, en als ik daarbij klaar ben, een aparte working copy uitchecken, met svn mv bestanden verplaatsen, en vervolgens uit de gerefactorde bestanden eroverheen kopiëren, en dat comitten zodat Subversion de geschiedenis en de wijzigingen bevat. Dat is wat meer werk, maar handmatig refactoren zou ik niet zien zitten als je er ook tool support voor hebt.

[ Voor 29% gewijzigd door Soultaker op 05-05-2009 13:31 ]

[Standeman]

NetForce1 schreef op dinsdag 05 mei 2009 @ 13:24:
je kunt een dump filteren met de standaard tools op de server, alleen dat kan lang gaan duren bij grote repositories

Ah, ik heb idd wat gevonden. Met svnadmin schijnt het idd mogelijk te zijn. De repositories zijn niet zo heel groot, dus het zou niet zo'n probleem moeten zijn.

En nu maar hopen dat ik niets verpruts Het lijkt er iig op dat ik de Subversion admin man hier ga worden

[ Voor 9% gewijzigd door Standeman op 05-05-2009 15:18 ]

[Soultaker]

Ik zou me trouwens niet aanwennen om voor "normaal" werk van svnadmin gebruik te maken. Je verliest daarmee de garantie dat gecommitte revisies niet meer verloren kunnen raken, en daarmee een van de belangrijkste voordelen van een source control management systeem.