Handling plus signs in directory names
I've been using subversion on a directory tree which has quite a lot of directories that start off with a plus sign and I'm getting error messages and problems committing changes which I never experienced before. Are plus signs in directory names handled well by subversion? Zé
Re: Handling plus signs in directory names
On 04/19/2013 07:58 AM, Thorsten Schöning wrote: In those cases problems often occurs because those sign are interpreted by the shell and not directly a problem for Subversion. Therefore you should provide some more details about who exactly you are committing, Shell vs. TortoiseSVN or any other app for example, the specific commands and folder names you use, the errors you get and of course what you mean by "never experienced before", e.g. did commits with the same commands or whatever ever worked on the same folders etc. The errors I've mentioned in the previous post were being thrown both through the shell (linux) and TortoiseSVN (windows). At the moment I can't provide more information, as I've been experiencing these problems with a SVN repository at my workplace and I wasn't able to replicate these issues on a test repository created locally. It's quite possibly that the errors I was stumbling on had absolutely nothing to do with plus signs in directory names. I'll report back if I manage to replicate this issue or if I stumble abain on one of those error messages. Best regards, Zé
How to setup a server?
Is there an official Subversion guide to set a subversion server? Thanks, Zé
Re: How to setup a server?
On 04/24/2013 08:52 PM, C. Michael Pilato wrote: The closest thing to "official" would be the Version Control With Subversion book (http://svnbook.org/). But don't expect to find an ordered list of steps to setting up a Subversion server, because that's just not the audience for that text. It would be nice if that sort of text was made available officially. At least I would be interested in it, and I believe others would too. But not to worry! A Google search for "guide to setting up a subversion server" only returns 1.35 million hits. Surely there's*something* of value out there. There might be, but it requires a bit of knowledge to be able to tell which have value and which are a complete waste of time. An official guide would offer some assurances that newbies wouldn't be wasting their time. If you'd like to avoid setting up the server yourself, you might consider looking into a more turnkey solution uch as CollabNet's Subversion Edge (http://www.collab.net/products/subversion) or WANdisco's uberSVN (http://www.wandisco.com/ubersvn). Third-party service providers aren't an option. Zé
Re: How to setup a server?
On 04/25/2013 02:29 PM, C. Michael Pilato wrote: Try reading Chapter 6 of the aforementioned book. It may be all that you need to read. After further review, Chapter 6 does have enough information to serve at least as a starting point. Disregard this thread. Thanks for pointing this out, -- Zé
Re: How to setup a server?
On 04/26/2013 12:36 PM, Nico Kadel-Garcia wrote: Did you mention your base OS? The versions available for different operating systems vary. I expect it to be linux, either Debian or Ubuntu. -- Zé
Re: trunk naming best practice question
On 05/07/2013 04:50 AM, Z W wrote: What's the best practice in use with SVN ? Maybe this can give you some ideas on how to organize your subversion repositories: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.branchmerge.commonpatterns From your description, it sounds like you are trying to implement the release branches approach. -- Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/09/2013 09:35 PM, Branko Čibej wrote: The real problem here is that Subversion does not treat/renames/ as atomic operations. I think that the real problem here is that Subversion doesn't support branches. The fact is that moving or copying a file or directory around is not the semantical equivalent of creating a branch. Therefore, if the same operation is used to perform both then one will not be supported as well as it could be. Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/10/2013 02:56 PM, Stefan Sperling wrote: It is strange behaviour on a conceptual level if you are used to thinking in terms of other version control systems (such as ClearCase in your case). However, it is a natural consequence of the way Subversion is currently supposed to represent the concepts of versioning files and directories, and labels and branches. And it has done so for over a decade. Changing this behaviour is far from trivial. I'm not entirely sure what kind of answer you are hoping to get. Are you happy with the answer that Subversion is simply not ClearCase? You are misrepresenting the problem. It doesn't matter if subversion isn't like any other SCM system. The problem is that the effect of copying, renaming or moving a file or directory around, as done by any SCM system, is incompatible with what's expected out of a development branch. Using svn copy to structure a repo to simulate branches and tags is a hack. The existence of a branch shouldn't depend on whether someone checked out an older revision or not, and creating a branch shouldn't appear on any file's history. Essentially the people behind all popular SCM projects understood this right from the start. Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/11/2013 08:46 PM, Stefan Sperling wrote: On Sat, May 11, 2013 at 06:45:03PM +0100, Zé wrote: You are misrepresenting the problem. It doesn't matter if subversion isn't like any other SCM system. The problem is that the effect of copying, renaming or moving a file or directory around, as done by any SCM system, is incompatible with what's expected out of a development branch. That's a matter of definition. It isn't. It's pretty straight-forward. If copying directories around ends up leaving traces on the revision history, which are forever stored and forever made available in the repo's history, then resorting to this hack to simulate branches goes against how developers expect a development branch to work, and is a nuisance to those who have to manage a repo and/or check its commit history. Recall that Subversion was designed to be better CVS. It was not designed to be an SCM system that fits anyone's definition of what an SCM system is and what kinds of abstractions it should support. I don't believe any SCM is developed that way. They are, however, designed to work properly. If creating a transient branch ends up being eternally stored in a repo's commit history then branching method isn't working properly. CVS had branches on a per-file level. That alone was deemed insuffient, so Subversion also has branches on a per-directory level. No, it doesn't. It offers the ability to copy and move the trunk directory around, and add that copy to the repository. That's not a branch. That's a hack intended to make do with what features were already available to try to simulate a branch. It works well enough this way for many use cases. But of course, it may not work for every use case, and if so people should use a different tool. You're missing the point. The point is that subversion could be even better than what it already is if it actually supported branches. Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/11/2013 08:25 PM, Thorsten Schöning wrote: I have a repo for binaries of one of our software which doesn't need installation, which gets directly deployed to our customers. Each customer is something like a branch or tag and some of the customers are grouped for some reason, sharing the same parent directories, share the same access rights etc. That's not exactly a development branch, but a directory tree. Subversion excels at versioning directory trees. Some of my repos contain web applications installed on different servers, again directly deployed as working copies and again different installations on the same server are grouped together under the same server name. I have only little experience with git almost a year ago, but what I remember is that git does support tags and branches and neither of those could be structured in any way, git only allowed one level for tags and branches. Tags/branches aren't directories which need to be organized in a deep hierarchical structure. A branch, as implemented by git, is similar to the feature branches approach mentioned in the manual, but properly supported by the SCM system. http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.branchmerge.commonpatterns Wit Git, when a branch is created it is expected to have a finite lifespan, which is supposed to end either by being merged with the trunk or being deleted, without leaving any trace on the versioning history. A tag is nothing but a pointer to a particular point in the repo's history. -- Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/13/2013 03:04 PM, Bob Archer wrote: What I don't understand is why someone argues about how git does something is better yet uses svn. Use the tool that works for you, or works the way you expect a tool to work. If you think my comments were about Git then you missed the point entirely. In fact, it doesn't even make any sense to single out Git, because Git isn't the only SCM system out there that actually supports branching. Regarding your comment about using the tool that works for you, it really only applies to hobbyists who work alone on their pet projects and are free to make any decision regarding any change to how they've organized it. When someone is a member of a team that is organized around a particular SCM system then that ceases to be a valid assumption. Nevertheless, I fail to see how that has any relevance regarding the way Subversion would be better if it supported branching. -- Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/13/2013 04:21 PM, Bob Archer wrote: Yes, I get what you are saying. But, to claim the way svn supports branches and tags is a "hack" doesn't seem like a productive conversation. It is far from a hack and that statement dismisses all the hard work of design and implementation that went into svn almost dismissing the whole team many of which are volunteers. It would be nice if branches could become a first class object with the branch command being very specific. But, what we have is far from a hack if you understand how it works. > I would like to see more "first class" support for projects and/or defining a project root. For example, perhaps there can be an svn:projectroot property that must be on a folder and the branch/merge command will only work on project roots. If that is done of course the maintain backward compatibility there could be a switch in the client config to allow for bypassing this requirement, or perhaps the --force switch could do it. Also, a property can be place on a branch so that tooling can know it is actually a semantic branch rather than just a fork (copy). No one is dismissing anyone's work. Quite the contrary. I don't know where you managed to get that idea. What has been said regarding subversions lack of support for branching was, I think, quite clear. You may prefer using euphemisms such as "first class support" to refer to the actual support for branches, and in the process actually agree with what has been said about subversion and branches, but that doesn't mean that referring to the same issue through different names implies that anyone is dismissing anyone's work. -- Zé
Re: UNS: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/13/2013 06:23 PM, Andreas Krey wrote: No, the basic difference is that VCS operating on the whole tree can only have branches (and thus merge info) on the whole tree either, so you*can't* go like subversion does and map branches into the tree and need to have them (and tags) as a separate concept. Compared to how other SCM systems handle tags, subversion also doesn't have tags as a separate concept. Subversion provides a way to pinpoint each commit objectively and unambiguously by specifying specific revisions. The only difference between subversion and other SCM systems is that other systems offer support for labeling and adding useful info to those revisions, while Subversion doesn't. If you are referring to the ad-hoc method of copying the trunk/branch to a subdirectory then all that you're doing is copying the trunk directory to another directory in your repository. That may be a convenient hack, but that isn't exactly support for tagging. Let's put it this way: if that was actually a tag then it could also be argued that any file system supports branching/tagging. -- Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/15/2013 04:04 PM, Les Mikesell wrote: On Tue, May 14, 2013 at 3:33 PM, Zé wrote: What has been said regarding subversions lack of support for branching was, I think, quite clear. Well, no. The only thing you've made clear is that you don't like it or you don't understand how it is supposed to be used. Read what I've wrote. Stick to what I've actually said, and don't put words in other people's mouths. You have not explained why you lay your projects out so that you need to move the parent directories of your project around after creating branches. You either failed to understand what has been written or you're imagining claims. Please quote exactly where I made such a claim. Nor have you made any real suggestions about how it might be improved I've already did. I've suggested that it would be great if subversion supported branching. People already replied to this thread saying that that feature is currently on the back burner. Next time try not to be rude and do read the posts you're replying to. Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/15/2013 06:59 PM, Les Mikesell wrote: On Wed, May 15, 2013 at 12:06 PM, Andrew Reedick wrote: Plus, telling people not use to svn's touted directory manipulation features because of side-effects is a bit self-defeating. Not if you want it to act like SCM's that have branches that don't allow such things. Don't you understand that *that's precisely the problem*? Currently, subversion does not support branching, and it's only possible to manipulate subversion to *act* like it does by copying around subdirectories in the repository, and in the process screw up with the repo's revision history. -- Zé
Re: UNS: Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/18/2013 06:33 PM, Thorsten Schöning wrote: Guten Tag Zé, am Samstag, 18. Mai 2013 um 18:24 schrieben Sie: The only difference between subversion and other SCM systems is that other systems offer support for labeling and adding useful info to those revisions, while Subversion doesn't. Which useful info besides the name, and always present things like a revision, timestamps, who made the commit etc. is this? And how does one benefit of those additional info compared to the lack of structuring of branches and tags those SCMs provide compared to Subversion? Subversion doesn't offer tags explicitly. The closest it has is revision numbers, and the standard course of action is to simulate this feature by creating a dedicated subdirectory that is used exclusively to store copies of the trunk whose names are selected to reflect tags. Having said that, the "let's copy the trunk to a subdirectory" approach to simulate tags is not a problem, nor is it a shortcoming. People have emulated tags by storing tar files containing copies of the trunk, and that works well. If you are referring to the ad-hoc method of copying the trunk/branch to a subdirectory then all that you're doing is copying the trunk directory to another directory in your repository. That may be a convenient hack, but that isn't exactly support for tagging. That's not an argument at all, because all one does in other SCMs is creating branches and tags. What you really should argue is what all devs think is common sense about branches and tags and why Subversion doesn't fulfill those requirements. That has already been repeatedly stated. Again, using the ad-hoc directory copy/move operations to simulate branches stores all the changes in the repo's revision history for all eternity, even when creating short-lived development branches which don't go anywhere and end up being deleted. The only thing mentioned until now is that revision numbers can change in the way subversion handles branches and tags and that only because Subversion does provide features, like (re)structuring branches and tags in a hierarchical way, other SCMs simply doesn't provide. That's the least of anyone's concern. The issue is that behind those revision numbers there are real changes made to the repository, which are eternally kept there and are made available to anyone. If you create a directory, change some files and delete the directory, and each operation is individually committed to the repository, each of those operations are eternally made available in the repository. This means you can checkout a specific revision that presents you with any of those changes. If you resort to those operations to emulate development branches, which is the only way that subversion is able to emulate them, then you end up storing in your repository revisions that reflect dead-ends which didn't made their way into the trunk, and those revisions do have an influence in subsequent revisions committed to the repository. Let's put it this way: if that was actually a tag then it could also be argued that any file system supports branching/tagging. You ignore the versioning part of Subversion and that it guarantees the state/history of branches and tags like any other SCM. You've missed the point. The point was that the suggested ad-hoc way to emulate tags with subversion is to copy a snapshot of the trunk to a subdirectory. That doesn't mean that a file system supports tags. Besides that, from my understanding filesystems do provide something which could be argued as support for branches and tags because branches are simply just work on something based on something other, which is implemented as copying files and directories, and tags are something which isn't as worked on as on branches, but is based on something other, too, and may easily be implemented using copying things around again and simply don't touch it anymore or e.g. using snapshots, which would better guarantee an unchanged content. That's essentially what subversion does, as the only thing it actually does is track revisions made in a specific directory. It works very well for a wide range of applications, in some cases better than other SCM systems, but the lack of support for branches does represent a a shortcoming. Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/18/2013 07:16 PM, David Chapman wrote: You are pretty insistent that there is One True Way to use branches in development. No, I'm stating that if all a SCM does is track changes made to the contents of a directory and you rely on changes made to that directory to emulate branches, then there are some significant downsides to this approach when compared with SCM systems which do offer support for branching. A lot of people do not agree with you. I've seen branches used as long-term development vehicles (think years), with only cherry-picked merges coming in from or going back to trunk. This does not match the definition of "use once and discard" that you are promulgating. You've missed the point. It's irrelevant if some development branches last for ages. The point is that when a SCM system does support branching, it doesn't matter if you organize your workflow based on development branches that last for ages or are only transient, because that SCM system does offer support for both of those approaches. With subversion, as it doesn't support branching, then you are only able to simulate them by making copies of the trunk and moving them around your repository, and although that approach doesn't cause any major problems if all your branches will be eternally worked on, it becomes a problem with transient branches such as those which are used in the feature branches approach. Subversion was designed as a versioned file system, in response to the shortcomings of CVS; concepts like branching and tagging have always been naming conventions built on top of that (later, merge tracking was added to assist branching). If you go back and look at the archives of this list, you will see this quite clearly. "trunk", "branches", and "tags" are simply naming conventions. I've been saying that from the start, and I've received some unfortunate replies for doing so. People don't even need to follow those, as has been noted time and again. This gives people a lot of flexibility, which they quite naturally use. That isn't being disputed. What has been stated, and stated repeatedly, is that it would be even better if subversion actually offered support for branches. And yes, ordinary file systems do support branching and tagging. I've seen it done. It's expensive, but it works. If you want Subversion to be extended in a particular way, learn its internals and write a spec which comprehends the internals and current usage. Maybe then someone will be inclined to work on it. Better yet, offer help. This is a community project, after all, and what better way to be a member of the community than to help? Right now you are not. As you may understand, not everyone has a lot of time to spend on side projects, and when they do then there's the problem of attaining the insight and technical know-how to do so. In spite of that, I don't believe that not being able to spend time contributing to a project justifies declaring a specific suggestion to be tabu. Forbidding anyone from, or attacking them for mentioning a downside or a shortcoming doesn't make it go away, and doesn't make the project any better than what it already is. What does contribute to its improvement is providing suggestions on ways to improve it, such as suggesting that implementing a sorely missed feature would be a significant improvement. Do you agree? -- Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/18/2013 08:33 PM, David Chapman wrote: On 5/18/2013 12:01 PM, Zé wrote: On 05/18/2013 07:16 PM, David Chapman wrote: You are pretty insistent that there is One True Way to use branches in development. No, I'm stating that if all a SCM does is track changes made to the contents of a directory and you rely on changes made to that directory to emulate branches, then there are some significant downsides to this approach when compared with SCM systems which do offer support for branching. You've missed the point. You have a specific definition of branching and do not believe that anything else can be called branching. You are confused. This discussion is about how subversion lacks any support for branching, which is quite obvious to anyone who understands and acknowledges that all subversion does is track revision changes to a file system. What you are insistingly referring to as branches is nothing more than a copy of a particular subdirectory (i.e., the trunk) into another subdirectory (i.e., branches), which is nothing more than a plain recursive directory copy operation on a file system. The operation doesn't change its name or nature (tag, trunk, simple server-side directory copy) depending on the directories which are copied around the repository. Is that so hard for you to understand? In your message to Thorsten Schöning, you said that branch history should be deleted if the branch is deleted. That is fundamentally in opposition to the definition of Subversion, which is meant to retain all of a project's history. Again, that's wrong. The only thing that leads subversion to track how a subdirectory is copied around in the repository is the fact that this is not a branching operation: this is nothing more than a plain file system operation. The point of this whole discussion is that subversion does not support branching, and therefore subversion users have to rely on the "let's copy the trunk directory somewhere in the repo to simulate tags/branches" hack to make do. Instead of relying on this hack, subversion would be significantly improved if it actually supported branches. How come you've replied so many times to this discussion if you are so oblivious to what has been discussed so far? -- Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/18/2013 09:16 PM, Johan Corveleyn wrote: So what's the actual problem (or problems) with SVN's branching and tagging? Where does it hurt your workflow? What would make SVN not "hurt you" in that way? Please be concrete, and give examples of what really bothers you as a user or an admin in your daily work. Saying that "branches are not first class", or "I don't like it that Subversion implements branches/tags by copying directories" are too abstract, and really not relevant. Why should I care how SVN implements its branches internally, as long as it works for the use cases I need? This has already been repeated multiple times. Didn't you followed the thread? Again, the problem is that subversion does not support branches or tags. All it supports is basic file operations on a file system, and they are not adequate for simulating branches or tags. here's a small, concrete, reproducible example. 1) Create a brand new repository: $ svnadmin create /tmp/repository 2) Set the repo initial layout: $ svn mkdir branches tags trunk 3) Populate the trunk: $ svn checkout file:///tmp/repository working_copy $ cd working_copy/trunk $ touch main.c $ svn add main.c $ svn commit -m "Initial import" 4) Start a feature branch by copying the trunk directory to a dedicated subdirectory: $ svn copy file:///tmp/repository/trunk file:///tmp/repository/branches/awesome_feature 5) Work on the feature: $ svn checkout file:///tmp/repository/branches/awesome_feature/ feature $ cd feature $ touch good_idea_but_undoable.c $ svn add good_idea_but_undoable.c $ svn commit -m "This is a dead-end development branch, doomed to be a complete waste of developer's time" 6) Delete a development branch subdirectory: $ svn delete file:///tmp/repository/branches/awesome_feature 7) This is the problem: $ svn checkout --revision 3 file:///tmp/repository/branches wc $ cd wc && tree ze@ubuntu:wc$ tree . └── awesome_feature ├── good_idea_but_undoable.c └── main.c 1 directory, 2 files -- Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/19/2013 09:33 AM, Dave Huang wrote: I use branches in SVN all the time… you might take Read the thread. -- Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/19/2013 09:51 AM, Zé wrote: Again, the problem is that subversion does not support branches or tags. All it supports is basic file operations on a file system, and they are not adequate for simulating branches or tags. Regarding tags, there's a better way to handle them in subversion: 1) Here's the repo status: $ pwd /tmp/working_copy/trunk ze@ubuntu:trunk$ svn log --limit 3 r6 | ze | 2013-05-19 09:58:38 +0100 (Sun, 19 May 2013) | 1 line Marked v2 r5 | ze | 2013-05-19 09:56:55 +0100 (Sun, 19 May 2013) | 1 line Marked v1 r1 | ze | 2013-05-19 09:35:25 +0100 (Sun, 19 May 2013) | 1 line Initial import 2a) This might be an alias to a "svn tag checkout v1" $ svn checkout -r5 file:///tmp/repository/trunk wc Dwc/this_repo_state_would_be_v2.txt Awc/this_repo_state_would_be_v1.txt Checked out revision 5. 2b) This might be an alias to a "svn tag checkout v2" $ svn checkout -r6 file:///tmp/repository/trunk wc Awc/this_repo_state_would_be_v2.txt Awc/main.c Checked out revision 6. These would be proper tags: they are immutable, they take over essentially zero space in the repository, don't store redundant information, and are completely free to be created and deleted. No network traffic is needed. I suspect that the only thing that would be needed for subversion to offer proper support for tags is to implement a list that tracked label names, revision number and the path to a specific subdir tracked by the subversion repository. -- Zé
Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?
On 05/19/2013 10:01 AM, Branko Čibej wrote: If Subversion does not support your workflow, then replace Subversion, or change your workflow. Did you even browsed the thread? This whole thread is on how subversion does not support branching, and how subversion would be even better than what it is if it actually supported it. And regarding suggestions on how to implement the workflow, feature branches are one of two workflows which are explicitly covered by subversion's documentation. Haven't you ever read the docs? http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature -- Zé
Re: Cost and Installation
On 07/04/2013 04:49 PM, Nico Kadel-Garcia wrote: It's an open source project. That means you can install it free, with your own engineer's time, pretty easily. The term "open source" only means that the source code is made available. Subversion's licensing is way better than that. Subversion is distributed under a free software license, which not only grants the right to access the source code (i.e., it's open source) but it also grants everyone the right to freely distribute it and also modify it as they may see fit. The second bit is the bit which is really important. http://subversion.apache.org/faq.html#collab -- Zé
commit all files except a selected few?
Does subversion support any command line wizardry that offers the user a way to commit the changes made to all files under version control except those made to a selected few? Thanks, -- Zé
Re: commit all files except a selected few?
On 09/15/2013 12:31 PM, Andy Levy wrote: On Sun, Sep 15, 2013 at 6:10 AM, Zé wrote: Does subversion support any command line wizardry that offers the user a way to commit the changes made to all files under version control except those made to a selected few? If you organize your files into changelists[1], you can commit a specific changelist and exclude other files. That wouldn't really apply to this use case, as it relies on pre-established lists of related files. Other than that, svn commit allows you to pass multiple files/paths to be committed. You can specify individual paths and/or use your shell to pattern-match or glob files which should then be expanded by your shell to pass to svn. That doesn't apply as well, as the objective would be to easily exclude a single file, or a small subset of files, from an arbitrarily long list of files. Thanks anyway, Zé
Re: commit all files except a selected few?
On 09/15/2013 02:39 PM, Zé wrote: On 09/15/2013 12:31 PM, Andy Levy wrote: Other than that, svn commit allows you to pass multiple files/paths to be committed. You can specify individual paths and/or use your shell to pattern-match or glob files which should then be expanded by your shell to pass to svn. That doesn't apply as well, as the objective would be to easily exclude a single file, or a small subset of files, from an arbitrarily long list of files. Silly me. The answer is, quite obviously, in specifying glob patterns, particularly one which excludes a file. With bash, the !(excluded) glob pattern does just that. So, thanks to bash, the following command excludes main.c++ from a commit: $ svn commit -m "committing everything except main.c++" !(main.c++) Once again, a little knowledge of the shell goes a long way. Zé
Commit ignoring whitespace changes
Does subversion provide a way to commit all changes except those that affect only whitespaces? Thanks, Zé
Re: Commit ignoring whitespace changes
On 09/25/2013 11:37 PM, Ryan Schmidt wrote: On Sep 25, 2013, at 16:19, Zé wrote: Does subversion provide a way to commit all changes except those that affect only whitespaces? Nothing built in for that, no. I recommend whitespace changes be a separate commit from functional changes. But it's up to the developers to do that. The tool doesn't do it for you. Bummer. It's a shame and a nuissance that subversion can ignore whitespaces on svn diff but not on commit. Zé
Fork and merge individual files
Does subversion provide a way to fork and merge individual files stored in various points within a repository? If it does, can anyone provide a small example showcasing this feature? Thanks, Zé
Configure user name?
Does subversion provide a way for the user to configure his username, thus avoiding having to pass the --username flag everytime he has to commit something? Thanks Zé
Re: Configure user name?
On 04/18/2014 04:41 PM, Bob Archer wrote: Does subversion provide a way for the user to configure his username, thus avoiding having to pass the --username flag everytime he has to commit something? Thanks Zé The credentials should be cached. If they are not being cached check in ~/.subversion/config, you probably have store-passwords = no. Change it to yes (or just comment it out because it defaults to yes), and the next time you give subversion your password it should save it. My question was if Subversion provided a way to configure the username. It appears that by default subversion forces the user to use his system username, and it also provides a way to specify a custom username through the --username option, but it appears there is no way to let a user configure a custom username. -- Zé
Re: Default user on commit
On 04/19/2014 02:22 AM, Nico Kadel-Garcia wrote: On Fri, Apr 18, 2014 at 1:53 PM, Branko Čibej wrote: On 18.04.2014 18:15, Justin Mrkva wrote: I have two local working copies, both on my local user account. I am managing commits for another user, so he sends me files and I check them in. It’s weird but we have our reasons for this. So I go into his working copy, replace the file in question with his copy, then do `svn ci --username other` and it works fine. But next time I go into my working copy, if I commit using `svn ci` without specifying username, it “remembers” the alternate username. Is there a way to keep these from “sticking"? sudo to another username when working with the other repository? It doesn't make much sense to create a new username just to handle a remote repository. In fact, that's not even possible if the user hasn't admin privileges. -- Zé
Re: Blocking root from SVN repository
On 08/27/2014 01:49 PM, Les Mikesell wrote: It's basically a bad idea to usefile:// access at all for anything that might be used under multiple user ids. Maybe even for a single user... Well, that sucks. If file:// is not to be used then what are the available options to those who only need a local svn repository and don't have the option to set up a server? Zé
Re: Blocking root from SVN repository
On 08/27/2014 03:53 PM, Les Mikesell wrote: It's not that you can't use it, just that it can't protect you from the things that can happen through direct file system access. Like accidentally deleting the whole repo or changing ownership or permissions. I don't see your point. There's also a likelihood that those accidents can happen on a remote server. But regarding my question, if file:// is not intended to be used, as you and Stefan Sperling argued, then what are the available options for those who need a version control system and can't set up a server? Is it even possible to deploy subversion in that scenario? Zé
Re: Blocking root from SVN repository
On 08/27/2014 04:15 PM, Andreas Krey wrote: The difference being that anybody can accidentally do a rm -rf on the part after the file - anybody who can work with the repo. (...) When you have a machine to place thefile:// to, you also have something to run a server on. If the machine you place the file:// is the same where you can accidentallly do a rm -rf, accessing the file:// through a server won't help you with that problem. Additionally, to those security-concious people, installing servers on your workstation just to access local repositories isn't exactly on the top of best practices. Don't you agree? And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? Zé
Re: Blocking root from SVN repository
On 08/27/2014 05:09 PM, jbl...@icloud.com wrote: On Aug 27, 2014, at 8:28 AM, Zé wrote: Additionally, to those security-concious people, installing servers on your workstation just to access local repositories isn't exactly on the top of best practices. Don't you agree? Not at all. Running a "server" which only answers to calls via the loopback interface (or local-domain sockets) is quite common. In fact, look at your machine's own process list. You will find a large number of helper processes that run with UIDs other than as root. Those processes tend to be configured by people who had to invest significant amounts of time and effort to know what they were doing. I don't believe this should not be expected, let alone required, from end-users who only wish to get a basic tool to perform a basic task. In fact, I'm not aware of a single version control system which forces that on anyone who only wishes to, say, keep track of the changes applied to a directory tree. The point of separating your repository access to a "server" process allows you to insulate file access permissions to one UID separate from your own (priviledge separation). If all users on a single box access the repository through this "server" process, you create a layer of abstraction and prevent file ownership/permissions flipping and actually _increase_ security and preserve the integrity of your repo. My point is that in a significant number of cases, "all users on a single box" means "a singleuser on a single box, who already has complete access to the repo files". It makes no sense to argue for these hurdles if they actually don't accomplish nothing. This means that all the requirements to learn and waste time configuring and managing servers aren't justified. Meanwhile, there are plenty of version control systems out there that don't impose any of these requirements. Zé
Re: Blocking root from SVN repository
On 08/27/2014 05:58 PM, Bob Archer wrote: -Original Message- And I hate to repeat myself, but I'll repeat for the third time this question: if file:// is not intended to be used, then what are the available options for those who need a version control system and can't set up a server? Zé Does the file server support SSH? There is no file server. This discussion is about local repositories on a local system (a workstation) managed and accessed by a single user. Be definition you have a server since the files are on it. Just run the svnserve deamon on it even if it is your workstation. This is the problem. I doubt anyone who claims this is a reasonable approach has even considered the problem and thought about how the solution is simply unacceptable. For example, picture the scenario where someone tries to pitch subversion to a version control newbie to use for such basic tasks such as track changes to a file tree present on his file system: newbie: "this version tracking thing sounds neat. how do I track this folder, then?" svn supporter: "well, you start off by installing Apache and mod_dav_svn on your desktop, register a dedicated user account to run the server, and setup a subversion server. Don't forget to read these books on the basics behind server management, or else you risk getting hit by a myriad of security problems..." Do you believe this is acceptable? Even plain old rsync -a is a far better alternative than this. Frankly, this approach makes no sense. It makes much more sense and much more efficient to simply abandon subversion and migrate to pretty much any version control system. I'm not aware of any other system who forces users to install, manage and run servers just to track changes made to a file. How is this acceptable? Zé
