• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Setting up and configuring Subversion and Bugzilla

 
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm working on setting up a Subversion and Bugzilla server. Are there any tips, tricks, gotchas, I should know about? I've used CVS(long time ago) and ClearCase before, but this will be my first experience with SVN. I think I'll be using Tortoise and Subclipse to integrate with our dev environment.

TIA.
 
author
Posts: 5856
7
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have you read: http://svnbook.red-bean.com/
 
Bai Shen
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Peter Johnson wrote:Have you read: http://svnbook.red-bean.com/



Reading through it now.

But I'm also looking for some best practices, etc. Do y'all just version your source code, or the whole project? How does it work with Subclipse?
 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Whole project" meaning what? IMO it's nicer to keep libraries out of SVN when possible, but most places I've worked at keep them in there anyway (as opposed to using something like Maven). It works fine with Subclipse, although we're having issues when we use TortoiseSVN in parallel with Subclipse and the command line--I've assumed version issues (all 1.5, but various sub-versions).

I have occasional plugin glitches and have to go to the command line sometimes, and occasionally have to edit .svn files by hand.
 
Bai Shen
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Basically, I have a lot of small(and some not so small) projects that were developed in Eclipse. These include stand alone applications, web services, and more. I need to move them into CM. To accomplish this I'm setting up Subversion. However, it's been quite some time since I used CVS, and I didn't setup the Clearcase server that we use for a few projects. I'm trying to figure out how to handle some of the projects where there are things besides just the source code. For example, several of the projects are deployed to a Tomcat server integrated in Eclipse. What's the best way to store all of these in SVN?

Oh, and we have a couple projects that aren't in Eclipse. So I need to figure that out as well.

This is the first time I've setup the whole CM process, so I'm trying to figure out that best way to do it.
 
Saloon Keeper
Posts: 22483
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, to start with, my take on projects is that just about the WORST thing you can do is make them depend on an IDE. It makes them very difficult to transfer from one person to another, and if you need to do some emergency changes to a system that's several years old, the IDE may have changed so much that you won't be able to do that urgent build anymore.

So #1 rule for ALL my projects is that you must be able to build them on a non-GUI system that doesn't have an IDE. Usually via Ant or Maven, and that there should be a README file in the project root that describes how to setup and do the build. Mostly I use Maven these days, because the setup part is much easier.

However, not being an idiot, I do archive the Eclipse .classpath and .project files, so that when someone does need the advantages of a GUI, they don't have to reconstruct the Eclipse environment. By using symbolic definitions and other amenities I can make Eclipse projects that are portable and not intimately tied to the setup of my specific computer the way that too many projects I've had inflicted on me over the years do.

For the benefit of the IntelliJ crowd, I also archive the IWP and IWM files, but not the IWS. The project and module definitions are portable, but the IWS has internal workspace state definitions in it, and it's created at need.

Very commonly I archive the source and support files, possibly the target file(s), but rarely the intermediate stuff. If the project is good, I can rebuild that, and because it gets created and destroyed so frequently, it would generate a lot of unnecessary SCM transactions. Plus waste space in the archive itself.

In the case of Maven projects, I put the entire target subtree in .svnignore. Since Maven can (and generally should) publish its products out to the Maven repository, the output ends up archived anyway, just not in Subversion. I can live with the fact that this means 2 separate repositories, especially since if I did the job right, I'll be secure in the knowledge that the code will be maintainable and recoverable for a long time to come. Partly because the environment I'm using was designed to be simple, but durable (and mostly open-source, so no lost binary utilities). Partly because Sun has an IBM-like commitment to backwards compatibility that a certain other platform has (to my great and repeated pain) doesn't.
 
Bai Shen
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:Well, to start with, my take on projects is that just about the WORST thing you can do is make them depend on an IDE. It makes them very difficult to transfer from one person to another, and if you need to do some emergency changes to a system that's several years old, the IDE may have changed so much that you won't be able to do that urgent build anymore.

So #1 rule for ALL my projects is that you must be able to build them on a non-GUI system that doesn't have an IDE. Usually via Ant or Maven, and that there should be a README file in the project root that describes how to setup and do the build. Mostly I use Maven these days, because the setup part is much easier.



-nods- I've done some work with Ant, but mostly as a user. Any suggestions on an easy way to replicate your Eclipse environment using Ant and/or Maven? I haven't used Maven before.
 
Bai Shen
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Okay, so I got Subversion installed in a Windows VM to test it. I'm using CollabNetSubversion-server-1.6.2-1.win32.exe I just accepted all of the defaults. Then I installed TortoiseSVN-1.6.2.16344-win32-svn-1.6.2.msi on my machine(not the one hosting the VM). Again, I accepted the defaults.

Then in the VM, I ran "svnadmin create repos" in the svn-repository dir. However, I can't seem to connect with TortoiseSVN. In the repo browser, I type in sbn://ip/repos but I get an error that the target machine is refusing the connection. I even turned off the windows firewall in the VM, but I'm still getting the error.

Any suggestions?
 
Bai Shen
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Turns out that the svnserve service didn't start for some reason. Weird.

After I started it, I now get the following error.

c:\svn_repository\repos\conf\svnserve.conf:20: Option expected.

Not sure what it's looking for. Line 20 is the password-db line. I'm using the default conf file with just the password-db line uncommented.
 
He's giving us the slip! Quick! Grab this tiny ad!
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic