Good SVN client?

After your recommendation I tried SmartSVN. With less than an hours experience I'm already impressed. One of my guys hates the icon overlays that TortoiseSVN imposes, so he should like SmartSVN. Setup was easy. Created a project and did a checkout. Commit did what it should. You can double-click files to open them right off the GUI. Seems pretty good.

Scott

I don't understand that comment - don't you have situations where you want to see your changes relative to the repository version? Diff-to-head is the single most common operation I use and that's been the same through all source control systems I've used.

Right, but it sounds like larwe is coming from a locking approach where conflicts don't happen and the only interesting operation is check-in at which point you'll want to see the changes you've made.

Andrew

Trivial, small team use can follow that model. You can get by for years, maybe an entire career, with only that level of understanding. SourceSafe exemplifies that use. On larger teams and projects, each revision is initially a private branch, subsequently merged back into the trunk or left as a branch. Merging revisions is an inevitable and integral part of this use. ClearCase supports this model explicitly and, I believe, exclusively. Your forehead is in grave danger of discolored bruising until the differences are made clear and internalized.

Sure, and you *can* do it. CLI will give you diff format, so you can do pretty much anything. But as a main way of work with VCS it is a waste of time IMO. After all VCS is to *automate* versioning, not to make one doing all by hand. Checking all changes by hand and merging them by hand is... a waste of time. Been there, done that. I do check if files I work on change in repository. But not too often. I merge often. If something goes wrong- I check, diff with previous version. Why should I be interested in all others work? And diff that with my local copy? If they failed to check their sources, I'd have a little chance to do it without them or a lot of time. I act on conflicts; to resolve them I need to grab other developer and check. But too many conflicts mean some problems with the whole project - management, design, work assignment. Need for locking files- the same. Need to diff local copy and repository too often- the same. Well, this is my opinion.

Then you want to check with your 'baseline', so to say, not with repository, as repository might be a few revisions ahead of your 'baseline' and contain changes from others. Well, larwe stated 'repository' and 'my local hard drive' in the context of subversion. I have assumed that terminology is from svn documentation. After all- he read it, didn't he? :P

Regards,

M.W.

Agree, I've used both models and much prefer the non-locking approach but I've seen time and again where the introduction of non-locking is a huge cultural shift for developers and that's true for all levels of experience. It's something that has to be taken into consideration when moving from VSS to CVS or SVN. Merging branches is really an orthogonal issue to locking/non-locking although it seems that there's a progression from starting out with local small teams with a single trunk and locking to larger, distributed teams with multiple branches and non-locking.

Andrew

I'm just starting to get into subversion and want to run it in true client server mode, (not httpd) with subversion server runing on the server, repository structure hidden from the client, then do all accesses via the svn daemon under inetd., which should sort out all the gory details

Started out trying to build and install subversion from source, but it needs so many libraries and addons, even for the simple svn protocol, that I gave up eventually and downloaded the solaris kit from collabnet. Ok so far, with the server side installed and running, but the client side is still up in the air in that although I downloaded the Tortoise client, it installs as a windows shell browser extension and allows direct acces to the repositories, via a nfs or share network drive, where this is expressly discouraged because of the possibility of repository corruption.

Have to admit., still finding my way around this and may be missing something, but would prefer a dedicated client application that talks only to the svn server using it's dedicated port. Client is then pointed to the server and project configured by name Can't find anything in Tortoise to set up defaults for server, or project xxxx, which would then provide a clean and secure key for repository access...

Comments ?...

Regards,

Chris

They're not exactly trivial projects, but they are projects that already have their structure imposed - in this case, they are all being ported from old assembly language to C and in the process it is absolutely critical (administrative/regulatory reasons, not technical) to keep the original execution flow and breakdown of functions and variables in specific sourcefiles. I.e. if MyFunc: was in fred.asm, MyFunc() better be in fred.c.

Unfortunately the original code design is such that parts that require (say) my specific expertise/domain knowledge are sprinkled in files amongst other code that can be handled by any member of the team. All the rest of the team is flying blind in the sense that they've never worked on a product of this kind.

Since we have 12 hours time difference between teams, this is / usually/ not a problem - in the morning I check against head, review changes and put comments/todos/"checked, ok" in their work, then update my copies. I work during the day while the other guys sleep, and commit in the afternoon. They do roughly the same thing. Every two days we have a teleconference where we open a VNC-type session and go over the sourcecode live on my PC, address questions, and set goals for the next meeting.

However if the guys on the other side of the world stay late and check something in during my workday, it really messes with me when I go to check in - I have to merge manually even though we are practically never touching the same areas of any given sourcefile and 90% of the diffs are added lines, which should be easy to merge.

Merge in Tortoise has not worked for me at all, the description and documentation talk more about how to merge a branch back into the trunk, which is not what's going on at all - I'm trying to resolve conflicts in the trunk.

I've downloaded a couple of the suggestions from this thread but have not had a moment to test them yet - I'll probably be able to have a breather next Tuesday to work on it.

Probably the single most frustrating thing for me in Tortoise is the way it lies about whether or not your local files match the remote copies. If the green icon doesn't unequivocally mean "your copy is guaranteed to be the same as HEAD" then the "feature" is a waste of time and shouldn't be there. This is an example of useless shell integration gone mad. A feature I can't trust is worse than one that isn't there.

the

Unless I've missed something, if there is a version A at the head of repository, and I create version A' from A, and someone else creates version A'' from the same A, then whoever checks in second is in trouble. I haven't found a solution that works other than to rename my local copy, get the latest version of the file off the server, and manually roll in my changes. But this is almost a secondary point, see below:

What if most of the others don't really know what they're doing and need you to at least read over their code before it can be considered done? I imagine this issue will be easier for the next few projects of mine, but this first one is a real bear from a knowledge transfer perspective. I've caught a lot of strange errors and expect that there are still many waiting to be discovered.

Actually I really want to check my copy against repository HEAD most of the time, knowing that HEAD will probably deviate from my local copy. See my message to MikeWhy and comments above..

And when I look at the repository in a browser, basically I'd like a view something like SS - you see the attributes of the head version of each file, and you can access a history for each individual file as you need to.

They're not exactly trivial projects, but they are projects that

====== I should clarify that I meant the small team VCS use case is trivial, not the project and most of all not the people involved.

I worked once for a firm with 10,000 very active developers, every last one of them apparently over-achievers. The revision thrash rate was unbelievably high. It's a different perspective, but an extreme one. Not everyone needs ClearCase. In fact, many who use it and suffer its quirks likely don't benefit from its real strengths. I suspect many look at their flat revision graphs, and mutter, what's the big deal? For them it's the wrong tool, just as VSS would be inadequate in the other situation.

Merge in Tortoise has not worked for me at all, the description and documentation talk more about how to merge a branch back into the trunk, which is not what's going on at all - I'm trying to resolve conflicts in the trunk.

===== Without trivializing your experience, I'll point out that I have never once had a bad merge with SVN. I can't begin to tell you where the problem might lie. Maybe look first at line endings, or tab/space conversions. It might be as simple as not flagging whitespace changes as significant.

Probably the single most frustrating thing for me in Tortoise is the way it lies about whether or not your local files match the remote copies. If the green icon doesn't unequivocally mean "your copy is guaranteed to be the same as HEAD" then the "feature" is a waste of time and shouldn't be there. This is an example of useless shell integration gone mad. A feature I can't trust is worse than one that isn't there.

========= I can agree with that. Keeping in mind, though, that Tortoise is a simple client and SVN doesn't push change notifications from the server. All Tortoise knows is the repository state the last time it checked, and whether or not you made local changes. When I do care about the icon, it's easy enough to update by right clicking the root node and selecting "Check for modifications." Unless everyone else is just sitting on their thumbs, it's a safe bet that it's out of date very shortly after you last checked. Or could be out of date. Race conditions are like that.

I don't want to be an apologist for SVN or Tortoise, let alone a zealot. I like having it in File Explorer, keeping in mind the obvious limitations of same. I don't remember if it was always this way. I'm sure I went through a transition like you're experiencing. I just don't remember it for the lack of trauma.

Yes - if you have conflicts. No, because it seldom happens, unless everyone works on the same file(s) (or even same portions of files) at the same time, which means broken project and a hell for developers anyway - regardless of VCS used (or not used). Automatic merges work, and fine. The same way, as 'patch'.

Yes, one *can* do everything by hand. But then what do you need VCS for? I can see another method, but the only difference would be not to rename anything or take everything from repository, just use diffs and make your additional copy of repository file on the fly. But I see it as a broken way of using svn anyway. What I am trying to say- your problems seem so bizarre, that they *not your real* problems.

Well, OK... I used vim for looking at *my* changes.

Don't you do reviews? Do they put in whatever they consider 'nice'? It seems that I was somewhat right- there *is* a problem with whole project. VCS will add to it, not help IMHO. If I may suggest - straighten the project first.

OK. What is your interface to subversion back-end from server point of view? Have you tried to use WebDAV? Access subversion usual way to check in, use WebDAV for diff-ing. You should be able to use it as a (possibly network) drive. As long as you want to use it yourself *only*, it might help without creating havoc.

OK, I seldom needed that, so I just used CLI.

Good luck,

M.W.

Because the merge is done at update time. 'svn up' merges repository and your local copy. It works, or reports conflicts.

M.

It sounds like you are mixing up a few things here.

The svn client libraries can access a repository using a number of different protocols - file, http (webdav, with or without ssl), and svn (with or without ssl).

With the "file" protocol, you are accessing the repository files directly. As long as your client software is not corrupt, it will do the right thing - even if other clients also access the same files at the same time. However, by the time you add layers of network-accessible file systems (nfs, samba, etc.), the precise locking semantics, caching, and file operation ordering get a bit fuzzy, and it's hard to be sure that there is no possibility of race conditions leading to corruption. The earlier versions of the file-system repository format had definite problems with nfs - this is not the case now. But "file" protocol access is only really recommended for single users.

The "http" webdav protocol lets the webdav server handle things like caching, synchronisation, locking, and access restrictions (passwords, read-only areas, etc.) and is thus a better choice for most users.

The "svn" protocol is specific to subversion - the svnserve daemon handles the actual repository access. It is actually a bit less flexible than http access, although current versions support as much access control as anyone normally needs (with http, you typically use apache as the webdav server, and can use any apache modules or configuration you fancy). However, as clients don't directly read or write files, it is safer if you don't trust the clients.

So if you are setting up a publicly accessible repository, where third parties can have write access, use svnserve. If you are using it for a single user on a single machine, user file. Otherwise, http and webdav is easy and flexible (although there is no harm in using svn).

Once you've figured out what protocol your server will run, use that same protocol on the client.

Yeah - it seems svn would be working a whole lot better if we were able to go with a 21st (or even 20th) century code structure. Unfortunately as I said, I have to stick with the old asm structure for administrative reasons. There are lots of globals and there are a few files which everybody is constantly modifying; it's not modular at all.

Partly to have access to historical information. We don't currently use our RCS to keep a modular project under simultaneous development by different team members (since our legacy code is not modular), though we will be doing this in the future with new designs.

I had the choice of doing this project (and the nine that come after) completely by myself or using some overseas resources who aren't experienced, but can be trained. So this is a combination training exercise and project. They are competent programmers, and generally well-motivated, but they don't have experience with this particular type of project. We have a coding style guide, and a design specification including full p-code for the project, but there are aspects of the assembly original that are very difficult to understand unless you were intimately involved in the development of that old version.

I guess you could call this extreme programming, poor man's edition. The teleconferences are our mini-reviews.

It is WebDAV.

Have you read "Version Control with Subversion"? It sounds to me like you are trying to switch to subversion from sourcesafe without having tried to read about the differences in terminology, design, and philosophy. SourceSafe is basically a pretty interface to a set of individual copies of the source directories. You can do much the same thing by making a copy of your source folder and renaming it "version

Subversion is different. In a situation like yours (if I've understood it correctly) where there are a bunch of files and different people work on different files, and sometimes different people work on different parts of the same file, you should not have branches at all. Everyone works from the trunk. When you start working in the morning, or want to synchronise your changes, you do an update. When you have made some progress, you do a commit. Subversion handles merging file changes, and changes within files during an update - if it cannot, because someone else's changes directly conflict with yours, it will let you know.

Branches are for when someone wants to work on a sideline - perhaps something that breaks the workflow for everyone else. Perhaps someone thinks that the program will be better if "fred.c" is split into "fred1.c" and "fred2.c". Rather than doing it in the trunk and messing up everyone else's builds, he does it in a branch. Once that work is complete, and you want to re-synchronise the two-fred branch with the trunk, you are doing a "merge".

Tortoise is not "lying" - you simply haven't understood how subversion works. It does not continuously attach to the server to monitor for changes, nor does the server continuously send information to your PC. So how do you expect Tortoise to update the little green icons? Should it read your mind and guess when you want to check the repository?

When you check out with subversion, it makes two copies of the downloaded code - one is in the directory itself (the code you see and edit), the other is in a hidden ".svn" directory. It is *this* checked-out copy that is used for comparisons and icons in Tortoise (and

If you want to compare your working copy to the head (or any other version in the repository), select "check for modifications" from Tortoise, and use the "check repository" to compare with the head.

Have a look at . You can read it on-line, download it, or buy the printed version. You'll get far more value for your time by reading the first few chapters rather than wading in and getting frustrated when subversion and/or tortoise and/or other clients don't work the way you think version control software works.

That's an important point: trying to use SourceSafe in the same way that one used VSS is going to doom one to a life of frustration. The two sets of tools are designed for different work flows. The SVN book does a good job explaining the workflow for which SVN was intended.

David,

Thanks for the detailed reply. Have been plugging away at it again today and (with help from the red book) have the following configuration at the server end:

Solaris 10, latest subversion package downloaded from the CollabNet site. Installed fine and am running as a daemon with the following ps output:

/opt/CollabNet_Subversion/bin/svnserve --daemon -r /export/projects

created a project using svnadmin:

svnadmin create /export/projects/client/xxxx/ms4

which creates an empty svn directory under .../ms4

At the client side, running Win2k, with both Tortoise and (today) SmartSvn clients installed. Someone else mentioned here that they had evaluated around a dozen windows clients and have to say that SmartSvn looks just about everything I was looking for. It's bad enough having to run windows for development anyway and the idea of a shell browser extension is not quite what I had in mind, though it does look like it works well and gets the job done. It's probably unfashionable, but I do try to stick to the idea of one program to do one job well, which means standalone apps, not bits glued on elsewhere. SmartSvn installed out of the box and connected instantly to the example collab.net repository, so seriously impressed thus far. Tortoise feels far from intuitive whereas SmartSvn can be driven at basic level without ref to the help files, always a good sign.

Ok, all running, but when I try to connect client to server repository, I get the following message:

"svn: handshake failed: you must specify exactly one of -d, -i, -t or -X"

Get the same result on a telnet to port 3690, while Tortoise returns a completely different error message about files and pathnames.

It's probably something trivial in the setup, but have you seen any of this before ?

Oh yes, am using the svn protocol on the server, not via httpd as svn protocol is supposed to be easier to get running initially. We can play with the httpd stuff later as time allows.

All this is really an attempt to tidy up the development environment for several projects and to impose structure on the whole process. I'm often the sole developer and it's been easier in the past just to do a tar or zip snapshot every day with a meaningfull filename, but it's not ideal and future projects may involve > 1 programmer. An rcs structure could also cover docs, hardware design schematics, pcb layouts, and everything else, so many reasons to make the effort to get it all working...

Regards,

Chris

Is this error message on the client or the server?

I'd first run the server without --daemon (for example, via a ssh login). That way you should see any error messages directly while running it. Also try connecting to it using the svn command client, perhaps from the same machine.

I'm not really an expert on fault-finding here (mainly because it worked for me, using both svnserve and a webdav server). It's a little unusual to have a Solaris server - most of the information and how-tos are for Linux or Windows.

What about 'dirty' hack of including source files to 'upper level' source file, thus making project modular? (I know, I know - this is really ugly, but IMO justified in this case) Adding (pre/su)fix to the file name denoting module or part? What about adding sections in file - by inserting descriptive comments - to ease automatic merge?

...

The project seems nice, on some abstraction level :).

Just out of my curiosity - how do they look like?

Regards,

M.W.

Or, by anecdote, "what you see is what you're going to lose". :)