Talk:Subversion (software)/Archive 1

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. This content was archived on 2007/12/2 from Talk:Subversion, a disambiguation page whose "talk" page had not gotten moved.

"Annoyingly Large"

NPOV in 'See Also' about SVK. svn working copies aren't neecessarily this. The statement is needlessly accusatory and needs to be rephrased - rernst 15:49, 2 November 2006 (UTC)

I removed the word "annoyingly". I think the sentence works as it is now --nertzy 18:25, 14 December 2006 (UTC)

"Feature limitations"

70.169.134.132 (talk · contribs) just dumped this bit of POV commentary in the article, which I've reverted.

Subversion's lack of support for certain common features distinguishes it from other version control products:

• Poor support for move/rename - Subversion does not directly support moving/renaming of files -- instead, this is kludged as a combined "copy" and "delete" operation, which can lead to confusing GUI states in visual clients such as TortoiseSVN, or rename errors with case-insensitive filesystems. By contrast, systems such as BitKeeper treat move/rename as a native operation.

This sounds more like a problem with your client than with Subversion. You're complaining about the inability or trouble of the TortoiseSVN programmers to read and understand a very simple and well documented system. And trying to heap it on Subversion.

• Difficulties with binary files - Subversion cannot easily manage large files or frequently changing files that would cause the repository disk usage to grow too quickly. Data can only be deleted from a Subversion repository via an awkward procedure whereby the server is taken offline, the entire database is dumped to a temporary file, filtered, and reloaded. This limitation also affects files that need to be permanently removed due to licensing or offensiveness considerations. It can be contrasted with CVS (which has a "-o" command allowing ranges of revisions to be collapsed), or Visual SourceSafe (which has a "store only latest version" flag).

That's actually two issues. You provide no evidence for your assertion that Subversion does not easily manage large files before moving onto the problem of removing content permanently from a Subversion repository. That's a problem inherent to many versioned systems, not specific to Subversion. And any comparison with VSS clearly shows the sort of background you come from.[1]

• Working copy file bloat - Subversion litters each directory of the working copy directory tree with hidden ".svn" directories, each containing 9 subdirectories and 20 - 30 temporary files. Often this multiplies the disk usage and overall number of filesystem objects by an order of magnitude, creating performance issues for other applications that scan the directories. (By contrast, Visual SourceSafe only adds a single file.)

Hmm. This might be a plausible critique of Subversion. I do find a total of 9 directories in most '.svn' directories. But your other figures are way out. It seems to only double the storage requirement and number of files. Do you even know what an "order of magnitude" is? And again VSS.

• No merge tracking - Subversion does not distinguish "merge" operations from ordinary file edits. By contrast, systems such as BitKeeper and Perforce track the origin of the merges, preventing the same patches from being accidentally merged more than once, and facilitating so-called "cherry pick" merges.

That's because Subversion is a centralised repository, not a distributed one. Tell me, just how would one "cherry pick" when there's only one repository? This is just stupid.

Some of these limitations are discussed in the Subversion roadmap.

Only renaming, merging, and possibly the working copy issue. The rest you made up. --Imroy 01:13, 9 September 2006 (UTC)

---

That's actually two issues. You provide no evidence for your assertion that Subversion does not easily manage large files before moving onto the problem of removing content permanently from a Subversion repository. That's a problem inherent to many versioned systems, not specific to Subversion. And any comparison with VSS clearly shows the sort of background you come from.

Okay, let me help you with the logic: The problem with large files is that they increase repository disk usage. Similarly, the problem with frequently changing files is that they increase repository disk usage. This is only a problem when there isn't an easy way to reclaim the disk usage. The main culprits are binary files, which are bigger and tend to generate much bigger diffs than source code. Also, with binary files it's generally safe to use something like "cvs admin -o" periodically to collapse away everything except a snapshot of the binary files from each major release. (SourceSafe is very simplistic, but even it allows you to at least flag them as "store only latest version". It's not ideal, but at least people checking out for the first time can successfully compile & run the application without need for FTP or some other distribution mechanism.) By contrast, with text files you generally want to preserve the complete history, because source code microevolution often contains important information. I also mentioned the related problem of not being able to easily purge offensive or copyright-infringing material from a Subversion repository, and IIRC is even discussed in the Subversion manual.

Maybe the caption is what confused you -- "poor support for manipulating revision histories" would have been a better caption than "binary files".

This sounds more like a problem with your client than with Subversion. You're complaining about the inability or trouble of the TortoiseSVN programmers to read and understand a very simple and well documented system. And trying to heap it on Subversion.

TortoiseSVN is the leading visual client for Subversion. "Graphical User Interfaces" are the leading way that people interact with computers. If you prefer some other interface, that's fine, but you are a minority. My complaint was that if you move/rename files using TortoiseSVN and try to commit, you get weird behavior. Sometimes it spuriously requires you to "update", even though your local copy is already at the head revision. Sometimes it displays more "added" entries than "deleted" entries. After the changes are committed, sometimes errors occur when you try to view the log history before the move/rename operation. These problems are DIRECT CONSEQUENCES of the fact that move/rename is a not a native operation in Subversion, but is instead simulated via copy and delete. These problems do not exist in other version control applications that treat move/rename as a native, first-class operation.

Do you even know what an "order of magnitude" is?

I apologize if my wording was sloppy. Here is an actual experiment with a source code branch from my work: The "exported" version (no .svn folders): 8.51MB, 976 files, 117 folders. The "clean checkout" version (with .svn folders): 17.3MB, 4376 files, 1297 folders. If that's not "bloat", then maybe I've stumbled into some kind of heretofore unknown English dialect.

That's because Subversion is a centralised repository, not a distributed one. Tell me, just how would one "cherry pick" when there's only one repository? This is just stupid.

My goodness, you seem to be very emotional about this subject. The concept of "cherry-picking" is to merge a subset of the changes from one branch to another. For example, suppose we have a "mainline" branch and an already shipped "1.0 release" branch. Let's say that a major bug was fixed in the mainline as part of revision #1024, but this revision also contained some other changes that we don't want. Cherry-picking allows us to isolate that bug fix and apply it to the "1.0 release" branch to make a "1.0.1 release". Let's say that later we decide to follow up with a release 1.0.2 incorporating revisions #1020 through #1050. In this case, the revision control software would remember what parts of the revision have already been merged, and avoid a merge conflict when merging everything else. It's an advanced feature, but many products do support this. I would be happy if Subversion merely tracked which entire revisions have been applied.

Only renaming, merging, and possibly the working copy issue. The rest you made up.

Maybe we have a different definition of "some"? More support for my "English dialect" theory.  :-)

—Preceding unsigned comment added by 70.169.134.132 (talk • contribs)

---

I think these are some good points -- maybe they could be incorporated into article somehow, e.g. in a feature comparison between revision control softwares? "Imroy" clearly has some kind of personal grievances with TortoiseSVN, he is not being objective.

72.82.83.251 18:38, 10 September 2006 (UTC)

---

Thankyou for responding. You seem more informed and level-headed than the original contribution of that section seemed to imply (to me at least).

Perhaps some of these issues can be incorporated into the article. Nothing is perfect after all. It's just that your addition struck me as overly critical of a project that is still fairly young, and blaiming Subversion for being something that it's not (e.g distributed). And the frequent mentionings of commercial software implied some sort of anti-FOSS agenda to me.

1. What you're basically saying is that Subversion needs some better tools to manipluate the repository. I think it's fair to say that. From my understanding of the API, there really isn't any function(s) to change past data, only make new revisions. The only exception could be altering "unversioned" properties i.e revision properties. I myself have had to edit the dump format when working on my Subversion-based wiki software (changed the layout in incompatible ways). Although it's something I eventually figured out, it's not something I look forward to doing again, nor is it practical for a team-based project to be doing this.
2. "TortoiseSVN is the leading visual client for Subversion". Maybe so. I use the command-line 'svn' tool under Linux and have had no problems whatsoever. I think it's fair to say that Subversion is intened for Unix and Unix-like operating systems. Just look at the support for symbolic links and the executable permission bit. It's no surprise if you're having trouble with case conflicts on an operating system that is case-insensitive and where the default file manager (Windows Explorer) purposefully mangles the case of files - try to make a file which is all lowercase and it changes the first character to uppercase. Having a single 'move' operation instead of copy+delete would be an improvement, but I still say your problem has more to do with TortoiseSVN and Windows.
3. Yes the WC is inefficient. I hadn't noticed until you pointed it out. And it's an issue listed on the roadmap page as needing improvement.
4. I understand what cherry-picking is. Isn't it only supported by a few RCS systems anyway? In Monotone (software)#Monotone as GIT inspiration it is claimed that Linus Torvalds opposes the idea of cherry-picking on various grounds. You may or may not hold his opinion very highly, but it could be argued that it's not clear if cherry-picking is a desirable feature. So it's a little unfair to say the lack of cherry-picking in Subversion is a limitation. The goal of Subversion has always been to replace CVS, with its simple linear train of changes. Subversion even simplifies this by having atomic transactions (i.e repository-wide revisions instead of a version number for each file) and replacing tags and branches with simple filesystem layout changes (/trunk, /branches/name, /tags/name). As you said, handling cherry-picking would require keeping track of individual patchsets and how they depend on each other. That would be quite a considerable change.

I'll look at adding some of these issues back into the article. But remember that we're trying to write an encyclopaedia here. We have to keep things neutral.

Oh and 72.82.83.251, I do not have "some kind of personal grievances with TortoiseSVN". As I said above, I think the problem has more do with the case-insensitivity of Windows and Windows Explorer. I fail to see how having to do a copy+delete instead of a single 'move' operation (as useful as that would be) has anything to do with TortoiseSVN's problems. --Imroy 19:52, 10 September 2006 (UTC)

The problem is not with TortoiseSVN or other UI clients but that a rename isn't 'atomic'. Users tend to be concerned if they see a file deleted and another one (with the new name) added when checking the status. They fear to loose the history (as they did with CVS when renaming files there).

And the case-insensitive problem is too a Subversion problem, not one of the UI. —Preceding unsigned comment added by 217.24.204.210 (talk • contribs)

How is the rename not atomic? Subversion uses transactions, which means a whole bunch of operations can be done in one atomic action. So even using the derided copy+delete, the 'move' is still atomic. In one revision the file has one name, in the next revision it has another name. Unless the client has screwed up (or the user has done so manually), there's no inbetween where both filenames exist. Also, the history is intact and one can follow the copy back through the history of the file. If TortoiseSVN can't handle this simple action then something is wrong, and it's not Subversion's fault.

Well, try moving some files to another directory, then accidentally do "commit" on the source directory but not on the destination directory. Oops! File got deleted! How is that "atomic"?  :-D 72.82.83.251 05:35, 16 September 2006 (UTC)

You have just demonstrated that you do not know what you are talking about. See my explaination immediately below. Unless you can come up with a real problem or explain it better, consider this matter closed. --Imroy 06:31, 16 September 2006 (UTC)

Are you simply referring to the fact that files can be moved or renamed by other software and TortoiseSVN doesn't know about it?[2] Hey, that's a common problem with any RCS on any operating system. And it has nothing to do with move vs copy+delete. You're either going to have to live with it or find a way to hook into the operating system and monitor those file operations.

And I beg to difer about whether "the case-insensitive problem is a Subversion problem". See, TortoiseSVN is the client. Its job is not only to interface with the user (the user interface), but also to the operating system on which it is running and the Subversion libs and/or server. Why shouldn't the TortoiseSVN client handle the local peculiarities of the system on which it is running? --Imroy 19:18, 14 September 2006 (UTC)

I don't really understand where you going with this. Is there some superior Windows GUI for Subversion? I think not. As far as I see, TortoiseSVN *is* Subversion for everyone except some minority of political activists who write software for operating systems that almost nobody in the world buy software for. Seriously, is there really an argument here that "command line is the future of how people use PC's"? It's a joke, right? 72.82.83.251 05:35, 16 September 2006 (UTC)

I don't really understand where you are reading these things that I've never written. If there is a superior Windows GUI for Subversion, I don't know and frankly don't care. Have I not made that clear enough? I do not have some vendetta against TortoiseSVN. To me it simply looks like you're taking a bug or problem in a Windows client and trying to pin it on the separately-developed Subversion server. That's like trying to blame Apache for the bugs in Internet Explorer.

As for "political activists who write software for operating systems that almost nobody in the world buy software for", I can only guess you're trying to take a jab at Linux and Free software. You failed miserably and revealed your prejudices. And I never said anything at all like "command line is the future of how people use PC's". Where the hell did that come from? Try to write something more constructive in the future, or just forget it. You've seriously compromised your position and I will have difficulty taking seriously anything you write in the future. --Imroy 06:31, 16 September 2006 (UTC)

You implied that these problems don't affect you because you use the command-line-only tools that come with Subversion, i.e. you are part of the minority of people who are willing to use software with no GUI. I don't see how it's any big difference -- the working copies are still basically the same, so I am sure these bugs (i.e. Win32 filename case bugs and non-atomic move/rename) affect the official Subversion command-line interface, too. If you doubt this I will do a test and post the results. You seem to think I am against open source, but I am using Subversion right? I just wish it was better than it is, and as such happen to agree with 70.169.134.132's complaints. 72.82.83.251 08:05, 18 September 2006 (UTC)

When I mentioned the use of the command line tool, I was replying to the other anonymous user about a problem that wasn't, at that point, explained fully to me. I wasn't trying to imply any sort of superiority or anything. I was simply saying what I used, and that I hadn't had any trouble. Since you've now revealed that this 'bug' is merely renaming or moving files without Subversion knowing, I can say that the CLI tool would in fact suffer from this 'bug'. As would every other revision control system (and all of their GUI's) that doesn't hook into the filesystem or implement the client interface as a filesystem (e.g Rational ClearCase, I believe). And you may be using open source software, but you certainly like dropping condescending references to those of us using software different than yours. The latest being the 'minorities' bit. Seriously, drop the attitude. --Imroy 08:37, 18 September 2006 (UTC)

I really don't see what subversions shortcomings have to do with this article. There are a million other places on the web to discuss versioning systems. This talk page is for discussing the wikipedia article on subversion. And most of the "shortcomings" are just nitpickings. Reub2000 07:41, 16 September 2006 (UTC)

Yes, this back-and-forth is now pretty much off-topic. A lot of articles have a section on criticisms or shortcomings, and that's alright as long as it's done fairly and with a NPOV. I would like to add in a few of Subversions "issues", certainly the ones mentioned in Subversion's own roadmap page [3]. It should be possible to write something interesting since they provide links to mailing list discussions, instead of just nit-picking and whining that Subversion isn't like some commercial package like the anon user(s) did. I'd also like to mention theway that Subversion handles tagging and branching i.e explicit paths in the repository. --Imroy 19:36, 16 September 2006 (UTC)

I agree too, it would make more sense to discuss in an SCM feature comparison, sort of like the one on this web site . Wikipedia have such comparisons for other tools, e.g. Comparison of vector graphics editors. 72.82.83.251 08:05, 18 September 2006 (UTC)

There's already the Comparison of revision control software article, it was linked right from this article. --Imroy 08:37, 18 September 2006 (UTC)

Isn't copy+delete atomic?

I see that User:Tobias Bergemann just made a small alteration to my new section on current issues. I thought I'd bring it here to the talk page since one or both of the anons above seemed to refer to something similar. It is this: I see copy+delete as being atomic. From the atomicity article:

An atomic transaction is a database transaction which either completely occurs (commits), or has no effects (rolled back). Guaranteeing atomic transactions frees the programmer from worrying about accidentally making partial updates to the database.

Using a copy followed by a delete to move a file is atomic if it's performed in the one transaction. In one revision the file has one name, in the next revision it has another name. There's no in-between, thus it is atomic. As are all transactions in Subversion. It doesn't really matter that it's done by two operations. If you follow the history of the new moved/copied file back in time, at some stage it will contain the copy operation from the old name and then continue on until the creation of the file (history in the Subversion filesystem only goes backwards). And the old filename stops being valid at the same point it was copied, unless the filename was reused and something else put in its place. How is this different from a move? I really don't understand the fuss about not having a single move operation. Can someone explain why they think it isn't atomic? Apart from a misuse/misunderstanding of the term. --Imroy 08:35, 20 September 2006 (UTC)

Try this experiment: Create a file "dir1/file.c" and a second directory "dir2". Now suppose someone does "svn move dir1/file.c dir2/" followed by "cd dir1", then he goes to lunch. When he comes back, he does "svn commit" and then goes home. The next morning a different person doing "svn update" will find the file completely deleted. (They must wait for first guy to come back, or else create a transaction that re-adds file by copying from a previous revision history, ugh.) So it's atomic from one perspective, but not atomic from the perspective of the guy whose file mysteriously disappeared.

Another issue is the logs -- if you move and rename 20 files and directories as part of a big project restructuring, the transaction log is pretty confusing. Even worse if file contents were edited. 72.82.83.251 21:13, 20 September 2006 (UTC)

Imroy I want to suggest something to you: Subversion has already succeeded. It has been adopted by SourceForge and GCC and lots of high profile projects, and is only a matter of time before surpasses CVS in popularity. I think we are past the era where it's useful to tell everybody that Subversion is perfect and awesome and has no flaws. We are in the time window where the project is still young and architecture has not yet become completely entrenched and inflexible like CVS. People need to be open and candid about these design flaws so that the community will think of solutions while such changes are still feasible to implement. 72.82.83.251 21:24, 20 September 2006 (UTC)

Wish List

Would someone please add a "Projects that use Subversion" section? - Meonkeys 01:06, 10 October 2006 (UTC)

Hi Meonkeys - there is a Users section that lists a number of high profile projects. I haven't found the source I was looking for, but have found the following that could be linked to:

• Who Uses Trac? - a link of users of Trac, who therefore also use SVN.
• Subversion Testimonials - A smaller list maintained on SVN's site.

Rather than include a long list, might it be better to link to an external page from the section? Cheers, --Leigh 11:43, 12 October 2006 (UTC)

• Yes, definitely. An external —non-advertizing looking— list is *the* way to avoid maintenance burden. I'm not sure this is in the Wikipedia guidelines, but it should be :-) — Gennaro Prota^•Talk 12:53, 18 November 2006 (UTC)

Comparison with other source control systems

It would be useful to the article to have a section in which Subversion is compared with CVS, SourceSafe, Perforce, and other source control systems. Benchmarks run personally by Wikipedia editors are unverifiable and not usable on Wikipedia, so these will have to be from a cited, reputable source. And of course benchmarks aren't the whole story, but any usability comparisons will also have to be from cited sources. Tempshill 18:50, 25 October 2006 (UTC)

It's right in the 'See also' section: Comparison of revision control software --Imroy 18:52, 25 October 2006 (UTC)