This week's book giveaway is in the Cloud/Virtualization forum.
We're giving away four copies of Building Blockchain Apps and have Michael Yuan on-line!
See this thread for details.
Win a copy of Building Blockchain Apps this week in the Cloud/Virtualization forum!

Craig Demyanovich

Ranch Hand
+ Follow
since Sep 25, 2000
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Craig Demyanovich

You're most welcome! Both of us benefit from these exchanges in that we sharpen our skills in preparation for the next issue!

Craig
Could the errors have anything to do with the approach that you wrote about in the thread on multi-project repositories?

After importing one project, try this command:

svnlook tree <path-to-repository>

It will show you the structure of the projects in your repository.

Based on your command, I expect it will show

You'll need to do an import like this:

svn import c:\tmp <path-to-repository> -m "import project1"

So you won't want to have anything else in c:\tmp other than your project1 folder (and below that, of course, you'll have trunk, branches and tags).

Hope that helps,
Craig
Oh, let's not worry very much, if at all, about trust here. We should check answers against documentation and our own experiences. When all doesn't agree, we double-check our sources, try again and ask questions until we succeed. This is how JavaRanch has worked for me, and I think it's what makes JavaRanch such a great place for learning!

Best of luck,
Craig
I haven't had any problems with the multi-project repository layout example that I showed. It was hosted on a Fedora Core 2 (Red Hat linux) server, and it was accessed via the svn+ssh (svnsever + SSH tunneling) protocol via the Windows command-line client and TortoiseSVN.

Craig
[ January 21, 2005: Message edited by: Craig Demyanovich ]
The recommendation in the SVN book goes something like this for a single-project repository:



and something like this for a multi-project repository:



Note that other nesting approaches are possible. See the "Choosing a Repository Layout" in Chapter 5 "Repository Administration" of the SVN book for details.

Craig
[ January 21, 2005: Message edited by: Craig Demyanovich ]
I think that both teams would use the same repository, whether it's located in one place or another. Subversion works well in a distributed environment, since the least amount of data possible for a given operation is passed between client and server.

For example, I work in Michigan, and the rest of my team is in Illinois and Florida. I just scripted our database, which is composed of 468 objects (tables, views, stored procedures, etc.), to my local hard drive, writing one file per object. It took me far longer to script it (~ 20 - 30 minutes) than to commit all 468 script files to our Subversion repository (~ 20 - 30 seconds). Both the database and the Subversion repository are located in Illinois.

Craig
[ January 21, 2005: Message edited by: Craig Demyanovich ]
Subversion ships with only a command-line interface. For a good Windows SVN GUI, check TortoiseSVN. For other SVN GUIs, I suggest starting your search here, where many SVN tools are listed.

Good luck,
Craig
Have a look here for CruiseControl and here for CruiseControl.NET.

Craig
Ali,

My gut feeling is that this won't work: I've never heard of anyone doing it, and the SVN book doesn't lead me to believe that it's possible. Nevertheless, someone with more experience may prove me wrong.

What don't you like about connecting to different repositories when you want to work with the project in each one? Are we talking about a large number of repositories if you go with one project per repository?

I think that best approach for you, given the concerns that you've expressed about repository revision numbers, is to try using SVN both ways. Set up one repository with a few dummy projects and commit a few changes to some of them. Then, repeat the experiment with a few repositories each containing one project. The projects don't need to be "code" projects; they could just be a collection of one or a few text files that are easy to change for the sake of the experiment.

Craig
My understanding is that "projects," groups of related files and directories, don't have their own revision numbers. Rather, the repository as a whole has a revision number. Any change in the repository increments the revision number.

For example, a new repository is a revision 0. Importing ProjectA increments repository revision number to 1. Importing ProjectB increments repository revision number to 2. Committing a change to ProjectA incrments repository revision number to 3. So, although ProjectB hasn't changed the repository revision number has. This confuses some people. They can choose to investigate it and adjust to it, or they can choose to do something like use one repository for each project.

Hope that helps,
Craig
Subversion repositories have a global revision number. It changes whenever *any* project in the repository changes. If people are uncomfortable with seeing the repository revision number change even though their project hasn't changed, then you could instead have one project per repository. Another idea is to put only related projects in the same repository, perhaps giving you a few repositories each with a few related projects.

Now, the advantage of a single repository is that security and maintenance (e.g., backups) need be configured only once. The disadvantage of many repositories, then, is that these steps may be performed many times.

You just need to find a balance between maintenance and what feels comfortable for your development team(s).

Craig
IDE support for SVN exists for

  • Eclipse (via subclipse plugin)
  • IDEA (via svnup plugin now and built-in (also as a plugin?) to next version, in development)
  • VS.NET (via ankhsvn plugin)


  • I suggest checking http://scm.tigris.org for getting a feel for what plugins are available. Other projects likely exist elsewhere.

    Craig
    I haven't tried RapidSVN because it looked ugly *to me*, and it didn't seem to be maturing very quickly. Maybe it's worth another look now. Although, TortoiseSVN and the command-line client are working well for me on Windows, which is the platform on which we develop at work.

    Craig
    I noticed that in solutions under control of VSS, the *.sln file shows entries like the one below when viewed with a text editor:



    This section is lacking in solutions not under VSS control. Are these sections stripped by the conversion process? If not, does opening the solution cause a connection attempt to VSS? One of my team members is concerned about this. Admittedly, we could just try it, but I thought I'd ask about your experience. Could you check one of your solutions now in SVN and report back whether a section like the one above remains?

    Many thanks,
    Craig
    Thanks for the speedy reply, Jeff. Hopefully, our fellow ranchers have some insight to share.

    Craig