[IDE en Subversion] Welke clients gebruiken jullie?

[JKVA]

Op TheServerSide lees ik net dat er een nieuwe SubVersion plugin voor Eclipse uit is. http://www.theserverside.com/news/thread.tss?thread_id=46224

Gebruikt iemand van jullie deze? Zo ja, hoe bevalt het? Zo nee, welke tooling gebruik je dan? En hoe bevalt die?

Ik gebruik zelf Tortoise in de Windows shell en dat bevalt prima. Echt een lekker werkende client. Ook nog geen problemen mee gehad.

In Eclipse gebruik ik Subclipse en die bevalt op zich ook wel redelijk, behalve dat ik op een bepaalde repo inlog met mutual authentication. Per actie die ik doe (ofwel vrijwel elke klik) vraagt Subclipse om het certificaat en de passphrase. Hoogst irritant.

En ja, wiseguys, ik ben het vinkje "remember my choice" ofzo niet vergeten.

Maar goed, iemand een goed alternatief voor Subclipse? Andere IDE is ook goed wat mij betreft...

[kenneth]

Ik gebruik TortoiseSVN, vooral omdat IDE's dingen nogal op hun eigen manier willen doen. Misschien heb ik dan de verkeerde plugins/proxy's, maar de afweging tussen het uitzoeken van het ene en het gemak van TortoiseSVN was zeer makkelijk
Ik had bijvoorbeeld in VS2005 bij een multi-project solution dat er meerdere commits werden gedaan, en daar zit ik niet op te wachten. Daarbij heb ik meerdere bestanden in svn dan alleen het project. Denk aan documentatie enzo. Hoort wel in de tree, niet in de Solution.

Waar komt dat SubVersion-met-hoofdletter-V steeds vandaan?

[JKVA]

kenneth schreef op dinsdag 17 juli 2007 @ 18:10:
Ik gebruik TortoiseSVN, vooral omdat IDE's dingen nogal op hun eigen manier willen doen. Misschien heb ik dan de verkeerde plugins/proxy's, maar de afweging tussen het uitzoeken van het ene en het gemak van TortoiseSVN was zeer makkelijk
Ik had bijvoorbeeld in VS2005 bij een multi-project solution dat er meerdere commits werden gedaan, en daar zit ik niet op te wachten. Daarbij heb ik meerdere bestanden in svn dan alleen het project. Denk aan documentatie enzo. Hoort wel in de tree, niet in de Solution.

Waar komt dat SubVersion-met-hoofdletter-V steeds vandaan?

Ik denk dat het komt omdat ik vrij veel programmeer en dus weleens te vaak op shift druk...

[zwippie]

Subversive heeft dan wel weer ondersteuning voor Mylyn, dus als je meer taakgericht met je repos, bugreports etc om gaat dan lijkt het wel leuk.
_{Heb er zelf absoluut geen ervaring mee}

[rollebol]

Ik heb enige ervaring opgedaan met AnkhSVN, een client voor in Visual Studio. Niet doen! Hoewel hij een stuk stabieler geworden is naarmate ze het hebben doorontwikkeld, blijven er nog steeds rare glitches optreden.

Net als de TS gebruik ik (en het hele ontwikkelteam bij mijn werkgever) TortoiseSVN (en af en toe gewoon de command line svn.exe) naar volledige tevredenheid.

[Creepy]

Ik gebruik voornamelijk Subclipse. Het probleem dat je hebt met steeds opnieuw aanmelden heb ik hier gelukkig niet. Voor zaken die niet vanuit de IDE worden gedaan gebruik ik Turtoise SVN (Windows) en de SVN commandline client (Linux). Werkt allemaal prima. Wil irritant is dat als je een file update de folder ook een nieuw revisienummer krijg waardoor je na een commit weer een update moet doen. Gelukkig is dit uit te schakelen maar dan lijkt het weer niet helemaal goed te gaan met de ignore settings e.d. van die betreffende folders.

[The - DDD]

zwippie schreef op dinsdag 17 juli 2007 @ 19:30:
Subversive heeft dan wel weer ondersteuning voor Mylyn, dus als je meer taakgericht met je repos, bugreports etc om gaat dan lijkt het wel leuk.
_{Heb er zelf absoluut geen ervaring mee}

SubClipse heeft die support ook.


Wat betreft tooling gebruik ik zelf altijd SubClipse en de commandline client.

Fijne van de commandline client is dat je helemaal zelf kan bepalen wat ie doet. Is met dingen als TortoiseSvn en andere tools soms wat lastiger. TorToise staat er op een windows box echter vaak wel op... Werkt soms toch net wat sneller via de explorer als je toch al aan het klikken bent.

[LuCarD]

rollebol schreef op dinsdag 17 juli 2007 @ 19:39:
Ik heb enige ervaring opgedaan met AnkhSVN, een client voor in Visual Studio. Niet doen! Hoewel hij een stuk stabieler geworden is naarmate ze het hebben doorontwikkeld, blijven er nog steeds rare glitches optreden.

Net als de TS gebruik ik (en het hele ontwikkelteam bij mijn werkgever) TortoiseSVN (en af en toe gewoon de command line svn.exe) naar volledige tevredenheid.

Ik gebruik AnkhSVN alleen voor commiten. Andere zaken zoals checkout/update en revert doe ik met commandline.

Wat voor een glitches ben je tegen gekomen met Ankh?

[Martin Sturm]

Wil irritant is dat als je een file update de folder ook een nieuw revisienummer krijg waardoor je na een commit weer een update moet doen.

Dat is toch juist inherent aan Subversion? Een revisienummer slaat op een hele tree, niet op een individueel bestand, zoals bij CVS. Hierdoor kun je met een revisienummer naar een specifieke toestand van heel je development tree verwijzen. Ik snap alleen niet waarom je steeds een update zou moeten doen van je folder.

[kenneth]

Nou, dat moet wel, maar om andere redenen Voor het committen even updaten om te kijken of er geen conflicten zijn enzo

[Creepy]

Als je een file update dan krijgt de folder waar die file inzit ook automatisch een hoger revisienummer. Hier lokaal heeft de folder nog het oude revisienummer dus zal er na een commit een update moeten volgen om ook dat nieuwe rivisienummer van de folder te krijgen. Als je dat niet doet en je wijzigt iets aan de folder (bijv. een igore setting) dan krijg je dus een conflict (in elk geval in Subsclipse.. met turtoise SVN of de commandline client heb ik geen last van dit soort dingen).

Als je een folder als een los iets zit dan zou een folder alleen een nieuwe revisienummer moeten krijgen zodra je iets aan de folder wijzigt (naam, ignore setting, whatever) en niet aan de files in die folder.

Een revisienummer van de gehele tree slaat inderdaad ook op de gehele tree maar files zelf hebben nog een eigen revisienummer, namelijk het revisienummer van de tree van het moment dat die file is gewijzigd.

[JKVA]

Creepy schreef op woensdag 18 juli 2007 @ 11:56:
Als je een file update dan krijgt de folder waar die file inzit ook automatisch een hoger revisienummer. Hier lokaal heeft de folder nog het oude revisienummer dus zal er na een commit een update moeten volgen om ook dat nieuwe rivisienummer van de folder te krijgen. Als je dat niet doet en je wijzigt iets aan de folder (bijv. een igore setting) dan krijg je dus een conflict (in elk geval in Subsclipse.. met turtoise SVN of de commandline client heb ik geen last van dit soort dingen).

Als je een folder als een los iets zit dan zou een folder alleen een nieuwe revisienummer moeten krijgen zodra je iets aan de folder wijzigt (naam, ignore setting, whatever) en niet aan de files in die folder.

Een revisienummer van de gehele tree slaat inderdaad ook op de gehele tree maar files zelf hebben nog een eigen revisienummer, namelijk het revisienummer van de tree van het moment dat die file is gewijzigd.

Nu je het zegt, met Tortoise heb ik dat probleem ook niet en met Subclipse wel. Misschien een bug ofzo. Het is iig erg irri.

Lol, vandaag ff consultancyklus gehad. Daar gebruikten ze zelfs TortoiseSVN om de source code te committen. Het klonk eerst vreemd, maar ik zat er in de file ff over na te denken, misschien ga ik ook 100% over op Tortoise, i.p.v. mezelf ergeren aan die versienummers en autenticatieproblemen in Eclipse...

[Creepy]

Heb er wel over zitten denken om dat ook te doen ja maar voor mij weegt het niet op tegen het compleet geintergreerd zijn in Eclipse en direct vanuit daar te de SVN zaken te kunnen regelen. Misschien toch eens kijken naar Subversive

[JKVA]

Creepy schreef op woensdag 18 juli 2007 @ 22:45:
Heb er wel over zitten denken om dat ook te doen ja maar voor mij weegt het niet op tegen het compleet geintergreerd zijn in Eclipse en direct vanuit daar te de SVN zaken te kunnen regelen. Misschien toch eens kijken naar Subversive

Precies, daar dacht ik ook aan. Minder tools open moeten hebben is ook een belangrijke pré, aangezien mijn taakbalk zichzelf toch wel vult.

Plus Tortoise 'vervuilt' toch een beetje je OS.

Heb jij al weleens een SVN geprobeerd te benaderen met mutual authentication? Dus een certificaat op de client?

[Creepy]

Nope, aangezien Eclipse de authentificatie gegevens onthoudt. 1 keer gebuikersnaam + wachtwoord opgeven en gaan. SVN benaderen we hier altijd via https:// (m.b.v. mod_dav_svn ) en niet via svn+ssh, svnserve o.i.d.

[ Voor 8% gewijzigd door Creepy op 19-07-2007 11:39 ]

[Niemand_Anders]

Wij gebruiken verschillende version control systemen. VB6 en Classic ASP projecten staan in SourceSafe. .NET projecten staan in zowel Team System (SourceSafe VS 2005+), CSV en SVN. Reden is dat wij met verschillende systemen hebben gespeeld. Omdat wij een volledig geautomatisserde test straat hebben maken wij momenteel gebruik van subversion.

CSV wordt bij ons niet meer gebruikt bij 'actieve' projecten. Wel staan er nog een aantal projecten in CSV waarvoor 1 of tweemaal per jaar kleine wijzigen op plaats vinden. Omzetten naar svn (inclusief history support) kost meer tijd dan het oplevert. Omdat wij ook linux/mac .net development doen is msbuild (nog) geen goede oplossing. Alleen subversion heeft momenteel goede integratie in de verschillende besturings systemen en in build tools zoals msbuild en nant.

Alle development (ook voor linux en osx) gebeurt bij ons in visual studio 2003, 2005 en sinds kort ook in 2008.

Samengevat gebruiken wij momenteel VS + svn. Onder windows worden project beheert via TortoiseSVN en TortoiseCVS. Omdat sommige zaken via een GUI wat lastiger zijn (aanklikken verwijderd bestand) hebben inmiddels alle developers uit ons team ook kennis van de cmdline opties.

[Verwijderd]

Wegens het niet kunnen vinden van een goede, werkbare plugin voor de Delphi IDE voor SVN of CVS zijn we 1,5 jaar geleden overgestapt op CS-RCS. Integreert prima met Delphi (in-RCS), VS 2003 en 2005, en met de explorer (zonder de icons compleet te verkloten zoals ik bij TortoiseSVN al vaak genoeg heb meegemaakt).

2 Nadelen:
- 't Is niet gratis voor closed source toepassingen, en
- Van repository wisselen kan niet vanuit de IDE of explorer, dat moet je doen vanuit de client die met de locale service babbelt.

Groot voordeel:
- Geen locale .svn of .cvs subdirectories nodig, dat handelt die client side service allemaal af.

[ Voor 3% gewijzigd door Verwijderd op 21-07-2007 15:39 ]

[dingstje]

Ik gebruik TortoiseSVN, enerzijds omdat het gewoon handig werkt en anderzijds omdat de IDE die ik gebruik (Zend Development Environment) enkel support heeft voor CVS. Ik weet overigens niet of ik zou overstappen op SVN-support in ZDE mocht het mogelijk zijn, het zou al zeer vlot moeten werken.

[Gwaihir]

Ik heb de vorige versie van Subversive gebruikt (1.1.1 of 1.1.2; weet het niet meer exact) en ben weer terug bij Subclipse. Ik had verschillende problemen met 't ding, wat mij een erg onveilig gevoel gaf ('t is toch je codebeheer) en kreeg van hun 'support' forum een weinig serieuze / professionele indruk.

[JKVA]

Gwaihir schreef op zaterdag 21 juli 2007 @ 16:23:
Ik heb de vorige versie van Subversive gebruikt (1.1.1 of 1.1.2; weet het niet meer exact) en ben weer terug bij Subclipse. Ik had verschillende problemen met 't ding, wat mij een erg onveilig gevoel gaf ('t is toch je codebeheer) en kreeg van hun 'support' forum een weinig serieuze / professionele indruk.

Wat voor problemen?

[Gwaihir]

1. Commits die niet plaatsvonden. D.w.z. hij denkt er een tijd over en cancelt ze dan. Geen idee waarom, gelukkig bleef dit wel zichtbaar doordat de '>' marker voor de bestanden niet weg ging (zoals na een succesvolle commit). Keek ik dan naar de console, dan liet die 'cancelled' zien, zonder verdere reden aan te geven.

2. Conflicten die niet zouden moeten bestaan. D.w.z. weigering tot commit, kennelijk omdat eerst een merge van me verwacht werd. Dat evenwel terwijl ik 100% zeker weten de enige committer was.

3. Geen 'checkout in folder van bestaand project'. Ik kon met het ding alleen een geheel project onder versiebeheer plaatsen. Ik ben gewend (met CVS overigens) binnen een project een of meerdere folders met de code te hebben en deze folders (met alles eronder) onder versiebeheer te hebben. Dat kan deze plug-in niet, waardoor hij dingen als de projectinstellingen en de projectcache (van bijvoorbeeld PDT) ook onder versiebeheer heeft geplaatst (en ik m'n notitietjes en andere scribbles nu in een los project bijhoud).

Deze ontbrekende feature heb ik bij hun support gemeld. Of beter gezegd, ik heb 'ja doen' geroepen in een al lopend draadje van een ander wat niet echt de aandacht leek te krijgen die het verdiende. Dat hielp niet: het was het laatste wat erover gezegd is aldaar.. Geeft het gevoel dat ze alleen bouwen wat ze zelf direct gebruiken en helemaal niet de aspiratie hebben tot SVN support voor Eclipse te komen op hetzelfde niveau als de CVS support (waar dit gewoon in zit).

Verder komt dat support forum (de reacties op andere problemen, de mate van spam aanwezig) toch al niet echt profi over. Maar vooral: je kunt als je daar leest duidelijk zien dat 't ding allerminst stable is en daarom neem ik het ze - gezien de aard van het programma - zeer kwalijk dat ze het toch als stable en 'stap nu over' adverteren.

[MisterBlue]

Voor mijn ruby werk gebruik ik de combinatie commandline, de svn-bundle in Textmate en Trac. Deze combinatie voldoet voorlopig, maar ik ben wel benieuwd naar het in Nederland ontwikkelde http://www.versionsapp.com/.
In java land gebruik ik ook de commandline en de intellij svn integratie. Tortoise heeft mij op een of andere manier nooit echt kunnen bekoren en voor de rest voldeed subclipse wel als ik eclipse gebruikte.

[Nick_S]

Wij werken hier ook met Subclipse in combinatie met Eclipse. Dit gebruik ik echter alleen voor updaten en diffs, aangezien subclipse niet kan omgaan met 1 commit over meerdere projecten (Maven2 modules, waar Eclipse niet goed mee omgaat)

Voor al het andere werk: bash + svn + mvn (Maven2 doet ook subversion commits, met releases)

CLI blijft toch het beste (Voor diffs gebruik ik dan kdiff3, welke svn automatisch aanroept).

[Jochem]

Ik gebruik (ook) subclipse voor eclipse. Werkt i-de-aal voor verschillende projecten (door elkaar). Eigenlijk gebruik ik ook op die manier veel open source libraries die ik link. Ik werk hoofdzakelijk met Python (pydev voor eclipse).

[eamelink]

Ik gebuik ook gewoon de standaardcombinatie van Eclipse + Subclipse. Al moet ik zeggen dat ik ook regelmatig de commandline svn client pak, of kdesvn. Verder draait er een trac op de server, en gebruik ik mylyn voor de integratie daarmee

[MisterBlue]

Is er ook een svn client waar ik makkelijk een timeline over de repository kan bekijken, net zoals in trac (zie bv: http://trac.edgewall.org/...hangeset=on&update=Update)?

[Nick_S]

Als je het net zoals Trac wilt, zou je Trac kunnen installeren op je subversion repository. Anders kan Subclipse ook de history laten zien van een bestand of directory structuur. Ik weet niet of dat voldoende is?

[MisterBlue]

Probleem is dat ik trac niet kan installeren omdat ik geen toegang tot de svn server heb. Ik wil het gebruiken om makkelijk te kunnen zien wat iemand bijvoorbeeld gisteren gedaan heeft en reviewen. Het handige van trac is dat je dan het hele overzicht op een pagina hebt.

[JKVA]

MisterBlue schreef op woensdag 15 augustus 2007 @ 19:43:
Probleem is dat ik trac niet kan installeren omdat ik geen toegang tot de svn server heb. Ik wil het gebruiken om makkelijk te kunnen zien wat iemand bijvoorbeeld gisteren gedaan heeft en reviewen. Het handige van trac is dat je dan het hele overzicht op een pagina hebt.

Als het gaat om het reviewen van nieuwe dingen, dan kun je gewoon kijken wat bij je update binnenkomt en daarop filteren. Tortoise of Subclipse laten bijvoorbeeld gewoon zien wat er allemaal nieuw is. Als je tegelijk met het reviewen de stukken binnenhaalt, werkt dat wel.

Of zoek je geavanceerdere reporting?

[MisterBlue]

Als het gaat om het reviewen van nieuwe dingen, dan kun je gewoon kijken wat bij je update binnenkomt en daarop filteren. Tortoise of Subclipse laten bijvoorbeeld gewoon zien wat er allemaal nieuw is. Als je tegelijk met het reviewen de stukken binnenhaalt, werkt dat wel.

Werkt wel om de laatste wijzigingen te reviewen, maar ik kan dan denk ik niet per revisie kijken wat er gewijzigd is.
De oplossing die ik nu maar kies is om met svnsync of svk een schaduwrepository op te zetten op een plek waar ik wel trac kan installeren. Misschien een beetje omslachtig, maar het heeft dan weer als voordeel dat ik het van overal uit kan reviewen met een webbrowser.