The Future of Subversion 173
sciurus0 writes "As the open source version control system Subversion nears its 1.5 release, one of its developers asks, what is the project's future? On the one hand, the number of public Subversion DAV servers is still growing quadratically. On the other hand, open source developers are increasingly switching to distributed version control systems like Git and Mercurial. Is there still a need for centralized version control in some environments, or is Linus Torvalds right that all who use it are 'ugly and stupid'?" The comments on the blog post have high S/N.
S/N Ratio (Score:4, Funny)
Well *I'm* ugly and stupid... (Score:5, Insightful)
Basically Subversion is not suited for development with a diverse population of loosely connected individuals, each with their own private branches. Frankly, for corporate work, I don't understand why you would want the backup and integrity hassles of a distributed version control system. But maybe that's because I'm ugly and stupid
Re:Well *I'm* ugly and stupid... (Score:4, Insightful)
Re: (Score:3, Interesting)
If I have n users in my software team and they each have a local repository copy and "commits" that they make are made to that local repository then it basically requires me to backup everyone's PC in order to ensure that work is not lost. I don't back up PCs, we have a clear rule that if you want something to be safe it goes on the server.
Now, sure, I can see that with some effort and mucking about you can ensure that everyone's local repository
Re:Well *I'm* ugly and stupid... (Score:5, Informative)
The big difference is that a DVCS adds a local workspace. I can check something out from the centralized server(with a DVCS, I pull the server tree to my local tree), mess around, make a branch, see what it does, decide it was stupid and throw the whole thing away, or I can decide it was a good idea and then commit it to the centralized server(by pushing my tree up to the central tree). The only real difference is that a check out is called a pull and a commit is called a push.
Separating change management from committing to the repository is not necessarily a bad thing. It may be undesirable in many situations, but it can also be handy.
Re:Well *I'm* ugly and stupid... (Score:4, Informative)
Re: (Score:2)
Hassle of creating a branch, eh?
How hard was that? You do all your work in 'skippy_post', checking in along the way. When you're ready to merge back, it is even easier.
Re: (Score:2)
Examples? Specifically, I'm wondering what advantages a DVCS can offer in a situation where what you would choose is very close to or exactly like the centralized model that something like Subversion forces on you -- and similarly, what the trade-offs are.
I know that's not the situation for most Open Source projects, but I think it is the case for a lot of businesses that are currently running Subversion, or are looki
Re: (Score:3, Interesting)
Re: (Score:2)
Re:Well *I'm* ugly and stupid... (Score:5, Informative)
A few months ago I switched to git. Git seems like the winner - it's fast, modular, and many people are hacking on it and have written many cool tools (most of which are "built-in" git "commands.") However, its Windows support lags behind the other front-runner Mercurial. Darcs is mostly used by Haskell hackers, Monotone never seemed to really take off, and Codeville has died on the vine.
The good thing is you can switch because there are migration tools for almost every one and the histories tend to be isomorphic.
Re: (Score:2)
Note to mods: I don't think the sibling post by gbjbaanb was a troll. A disagreement does not a troll make. His post was on-topic and not insulting so I really can't see why somebody would mod it as 'troll'.
Re: (Score:3, Informative)
(I put the disclaimer about unix boxes in because the last time I had a colleague on a Mac running SVK, there were some minor issues around binary files and line ending munging... I don't know if they are resolved already or not...)
Re: (Score:2)
Doesn't SVK [bestpractical.com] start to fill that role?
Re:Well *I'm* ugly and stupid... (Score:5, Funny)
Of course a CVS user only updates once a week and checks in once a month, so being on the beach for a few days wouldn't make any difference at all.
I have used Subversion, git, and most recently CVS, and the only big risks I've taken have been with CVS, where everything is so constrictive and painful that I tend to check in as little as possible. The bottom line is that whatever makes for the easiest, most natural development process will result in more frequent check-ins and less lost work.
(I've just stopped asking my colleagues, "How do I ___ in CVS?" because the answer is always slack-jawed silence, followed by, "Why would you want to do that?" accompanied with a suspicious squint-eyed stare that makes me feel like I'm in Deliverance, right there in a cube farm full of college-educated yuppies. CVS warps your brain to the point where you don't think there is ever any good reason to, say, rename a directory, and anyone who wants to rename a directory must be some kind of alien, possibly a marketer or a salesman who wandered into the wrong department, because a Real Programmer would never think up such a bizarre idea as renaming a directory to reflect its current contents. I mean, you pick a name, and it stays forever, right, like a street name! You don't go to Market Street and expect to find a market, so why are you surprised to find the networking code in the tpe_bckp directory? Gary Graybeard can tell you all about how it got that way, and it's a fascinating story. Think of all the rich history that would disappear if you renamed it the "net" or "networking" directory. So depressingly literal. And speaking of depressingly literal, the history would *literally disappear*, and the whole reason we have a SCM system is so we don't lose history. So don't go making changes that it doesn't know how to track, you hear?)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Interesting)
There's no reason you can't have a central "official" repository that everyone "pushes" their changes to.
How is that substantially different from what the OP described?
In any event, anyone advocates distributed version control has never been responsible for protecting the work of hundreds of developers working in multiple timezones/continents. Enterprises cannot afford the cost in time and money to back up every single workstation; developers have to be given a way to sync their work, at least once a day, with a central repository that can protected against data loss.
Re: (Score:2)
The worst-case loss in the event of a total failure of a single computer is one developer's local changeset(s), but that's the exact same risk when working with a centralized system as well. A developer's uncommitted work can always be lost if precautions aren't taken.
This is why you have nightly cron jobs that check in a developers work on a regular basis, before the nightly backups of the central repository kick off. It's not perfect, but it helps, and most devs get used to it pretty quickly (and are grateful for it when the inevitable hard drive crash happens on their workstation).
Re: (Score:2, Insightful)
Look - it's a tool - you can use it responsibly or use it irresponsibly - with the right set of rules and processes I'm sure it can be made to work. Local checkins are what really get my goat
Re: (Score:2, Interesting)
Re: (Score:2)
Re: (Score:2)
You can use any tool badly, but some tools are easier to use badly than others.
Re: (Score:2)
Yes, but the point is that it encourages and allows behaviour that is not desirable in a corporate development environment - local checkins. You CAN push your changes to it but equally you CAN just check stuff in locally. In some contexts this is great - but I think in corporate environments it promotes risky behaviour.
Look - it's a tool - you can use it responsibly or use it irresponsibly - with the right set of rules and processes I'm sure it can be made to work. Local checkins are what really get my goat ;-)
I think local checkins promote better behavior. With traditional version control the work developers do between checkins is not backed up and has no version control applied. That's ok if people are checking in often but if checkins are only happening every few days or less often then it can be a problem. With local checkins you at least get the benefits of version control locally. And let's face it: if you can get developers to a central VCS system then you can get them to push their changes to a central r
Re: (Score:2, Interesting)
In my environment servers are backed up and PCs are not, which is why local repository copies I think are risky.
I appreciate that you could add this sort of feature to a centr
Re: (Score:3, Informative)
Maybe it's not the same thing though. To me, the key difference would be running your own private SC server locally to handle the feature vs
Re:Well *I'm* ugly and stupid... (Score:4, Insightful)
subversion is good for small projects, or larger projects with limited number of developers.
Once you get into the hundreds and thousands of developers working on the same project though you need to think a bit differently in terms of needs of the individual developer, and the group as a whole.
Uhm... (Score:2)
(*) Don't know about any other systems than Bazaar, but I expect they have similar functionality: Bazaar has "checkouts" which enable you to have a local branch (i.e. on C:/Projects/Whatever) while also auto-committing to the "source" (i.e. the shared directory/drive) when you do a local commit.
Re:Well *I'm* ugly and stupid... (Score:5, Insightful)
Correct me if I'm wrong, but isn't this the major selling point of distributed revision control? The idea being that since it is a distributed repository, everyone has a "backup" of someone else's repository (depending where they got their code from). No distributed copy is necessarily considered more important than another. However in a corporate environment I would imagine it works out quite well since there's an inherent hierarchy. Those "higher up" can pull changes from those "below". Those "higher" repositories you could (and probably should) backup.
As far as integrity goes I think one of the main goals of both Mecurial and Git was to protecting against corruption (using a SHA1 hash). You're much more likely to get corruption through CVS and SVN, which is awful considering it's in a central location.
Re:Well *I'm* ugly and stupid... (Score:5, Insightful)
By backup - I mean a tape or location where I know I can look to find the "good" copy that contains the official tree of code that represents what is going into my product. What you are describing is copies of repositories sitting in various locations that isn't really the same as a backup. It's also a bit upside-down - I don't want to be "pulling" fixes from engineers, I want engineers "pushing" fixes into a known-good integration environment.
By integrity - I mean ensuring that you have all of the fixes you want to have from everyone who should be making changes on a project. NOT file corruption.
Re:Well *I'm* ugly and stupid... (Score:5, Insightful)
In a distributed environment usually there's someone's (or a group's) repository that's considered more important than others. In a software setting this could be a Lead Engineer's/QA/Certification's repository. Depending on what your definition of the "good" repository is, you would take the copy from the right place. It opens up in terms of flexibility what code you actually want to get to work with. The upcoming released version of your software from QA, the next-generation stuff that developers are working on, or maybe a new feature that you here so-and-so is working on...
But you have someone who needs to approve a change to a central repository that everyone shares. Right? That person would probably want to examine those changes before they're committed. The only difference between distributed and centralized, in this case, is that it's a required step. Everyone is responsible for their own repository.
I'm no expert on distributed revision control, so anyone please feel free to correct me.
Re: (Score:2)
Distributed VCS can be used like this (Score:4, Insightful)
Re: (Score:2, Insightful)
Yes, if you are disciplined about how you use it then I'm sure you can use it like any centralised VC. It is a tool - it is not evil - it just encourages what I see as risky behavio
Re: (Score:3, Insightful)
Huh ? If you don't push to the main repo, nobody sees your commits. Don't you think this is sufficient to remember DVCS users they need to push regularly ?
Re: (Score:2, Informative)
I take your point - if you are responsible in how you use DVCS then I can see that it can be made to work. But in my environment I want all of the changes being made (however offensive or broken) to be centrally auditable and not stashed away in some private repository.
Re:Distributed VCS can be used like this (Score:5, Insightful)
How do you force your cvs/svn users to commit ? You can't, you expect them to be responsible and do it. This isn't much different from a DVCS.
What if a user wants his work to be backed up but doesn't want to commit because his changes are not ready to be published ? A centralized VCS forces them to commit with the side-effect of making their unfinished work immediately visible in the central repo, while a DVCS lets them commit to a private repo that you can back up independently.
Your backup requirements can be solved 2 different ways:
Besides, in this debate, you are completely ignoring the other major advantages of DVCS over centralized ones: scalability, no single point of failure, possibility to work offline and have full access to all of the features of your VCS, usually faster than centralized VCS, low-cost branching/merging, etc.
Re: (Score:2)
Except that at a corporate environment only low-cost branching merging holds.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It's always possible to have some psycho who does an svn export and makes his
Re: (Score:2)
Re:Distributed VCS can be used like this (Score:4, Informative)
> on a disk which may not be backed up. I see changes being made to a codebase like valuable
> little bits of gold which need to be kept somewhere nice and safe
As a developer, I'll tell you that not all changes are "little bits of gold". Sometimes I just want to try something out, and end up with little bits of crap. The way to think about local changes is the same way you think about non-committed changes to your Subversion repository. In Subversion, I will have plenty of changes sitting on my disk, they just won't be committed until I am satisfied with them. In git, I can commit as many times as I like to my local repository and push only the final version to the central branch. This way I can checkpoint my code with intermediate commits. This is extremely valuable, since those checkpoints might not even work at all, and I would never want them to break the main build, but I can still break up my task into little subtasks and redo or revise each one of them in turn. These subtasks are not backed up in your scenario either, and are much harder to manager there.
Re: (Score:2)
You may consider them "bits of crap" - but I'd rather have your work, no matter how crap you consider it, somewhere where I'm relatively certain I can recover it if your laptop or PC craps out. You can still have them on a private branch (this is what I encourage - so they are backed up!) and you get the su
Re: (Score:2)
> you consider it, somewhere where I'm relatively certain I can recover it if your laptop or PC craps out.
Why? The chances of hard drive failure are extremely low. In my entire life, I have only had it happen to me twice. If you don't buy used drives on eBay, it will probably never happen to you at all. But let's say it happens once every ten years. A temporary branch of the kind I was talking about is probably o
Re: (Score:2)
Regarding costs of backup - basically the repository is just mirrored on a daily basis - so recovering the entire repository is probably not half a day but an hour at most. And the chances of l
Re: (Score:2)
One possibility, if you want a low-time-cost way to try a DVCS, is to try SVK [bestpractical.com] on an existing svn server.
To make it easy, I've copied and paraphrased the quickstart I was given for the first time I was introduced to SVK...
Re: (Score:2)
Re: (Score:2)
Seeing what people are up to is also a lot easier in a centralized system if people are committing - having to go and dig around in a bunch of private repositories is a major pain. And the visibility into work in progress requires publishing their private repository, so that needs to be enabled just the same as it needs to in SVN
Re: (Score:2)
I run the IT systems for my small software company and frankly Subversion is a great tool for the job. I don't *want* a distributed VC system because I don't want the hassle of trying to ensure that everyone's modifications to the code tree are backed up correctly and stored safely somewhere. I want it in a central spot I can back up and manage without my employees having to worry about it.
Clearly you have no idea how DVCSes work. Every employee has his own backup and you still can tell them (or force them) to push changes to a blessed server (which can be called central, but this isn't a _technical_ thing anymore), copy of which you can then safely stash away.
There are two things a DVCS can't do that a CVCS can:
1. Delete something from global history (just can't be done, because everyone has his own backup)
2. Partial checkouts (if you've got a monolithic repository instead of per-projec
Re: (Score:2)
Contrary to what you say, it doesn't seem to me that you can force people to push all of their changes through to a blessed server. People can work independently until it is time to release and this is made possible
Re:Well *I'm* ugly and stupid... (Score:4, Interesting)
SVN Sticking around? (Score:2, Funny)
Git vs Subversion (Score:5, Informative)
1. timestamps. Subversion doesn't do that by default, but it has good enough metadata support than timestamps can be hacked in easily. For Git, metastore is nearly worthless. If you store a program source, you risk just skewed builds -- for other types of data, lack of timestamps is often a deal breaker.
2. move tracking: trying to move a directory branch from one dir to another means you lose history. Rename tracking works only sometimes, often it will take a random file from somewhere else, etc.
3. large files. Take a 100MB binary file into SVN, change one byte, commit. Change one byte again. And again. Git will waste the freaking 100MB for every single commit.
4. partial checkouts. If there's a 5GB repository, you'll often want to check out just a single dir. With Git, there is no such option.
5. ease of use. I see that ordinary users, web monkeys and so on can learn SVN easily; with Git, even I had some troubles initially.
On the other hand, SVN used to have no merge tracking (I wonder what that "limited merge tracking" in 1.5 means...) which for distributed development of program sources is worse than points 1..5 together.
Re: (Score:2, Insightful)
They've been working for years to do simple
Re:Git vs Subversion (Score:5, Informative)
As a matter of fact, a guy doing a demo at an Apple Developer conference once used the svn codebase as 'something big to compile' when demonstrating the XCode IDE. When we asked why he used svn, he said that it was "the only open source codebase he'd ever seen which compiles with no warnings."
If you have specific criticisms about the codebase, we'd like to hear. Instead, your post just seems to be about how your personal wish-list of features has never been added, and therefore "the codebase must be really bad." I'm not sensing any logic to this conclusion.
svn 1.6 is going to likely have
The fact is: we haven't added your pet features yet because we've been too busy working on other big fish, like FSFS, svnserve, locking, svnsync, SASL support, changelists, interactive conflict resolution, and oh yeah... automatic tracking of merges.
The working copy code was designed in a specific way -- the scattered
Re: (Score:2)
I can't wait for better merge tracking, that's my number one hot-button issue.
Re: (Score:3, Interesting)
SVN_ERR(dir_baton->edit_baton->callbacks->file_deleted
(NULL, NULL, path,
textbase,
empty_file,
base_mimetype,
NULL,
baseprops,
dir_baton->edit_baton->callback_baton));
Four level of indirection to call a method with 9 parameters... really? Come on.
This is what object-oriented programming looks like in C, when there's no C++ to make it pretty. You have function pointers and their associated "closure' context objects being passed around everywhere as pairs. And lots of tables of function pointers (vtables). So in this example, we have a local closure object (dir_baton) referencing a vtable within a parent closure object, and calling a function from that vtable.
Go look at GTK/GNOME: they have the same sorts of problems, though they tend to do thing
Re:Git vs Subversion (Score:4, Interesting)
I don't see what you are talking about. git timestamps every commit too.
> 2. move tracking: trying to move a directory branch from one dir to another means you lose history.
No you don't. If you use "git mv", like you're supposed to, history moves with you.
> 3. large files. Take a 100MB binary file into SVN, change one byte, commit.
> Change one byte again. And again. Git will waste the freaking 100MB for every single commit.
No it won't. In fact, it will use less space than SVN for that commit. Yes, git supports diffs on any kind of file, and stores them that way. It didn't always, but the current version certainly does.
> 4. partial checkouts. If there's a 5GB repository, you'll often want to check out just a single dir.
That's what git submodules are for. Furthermore, git repositories are smaller than Subversion repositories by a large factor. At least twice, and I've seen as much as a tenfold reduction. Linux 2.6 repository is only 255M in size, and that's a huge project. Anything you do will likely be much smaller.
> 5. ease of use. I see that ordinary users, web monkeys and so on can learn SVN easily;
Bullshit. The commands are almost exactly the same. I don't know what people are complaining about.
Re:Git vs Subversion (Score:5, Insightful)
To commit a change to the Linux kernel, you do need to build the whole thing. That's a monolothic thing.
To commit a change to a webpage, a graphical project, a set of biochem data, you don't need that. Do you need to check out the countless megs of Wesnoth to update your changes to a campaign? That's a modular thing.
Depends on the environment (Score:5, Insightful)
If you're in a highly-distributed development environment like Linux, where the developers are spread across multiple continents and have very little shared infrastructure and a high need to work independently of each other (either because of preference or because they don't want their work stalled by another undersea cable cut half a world away), then yes using a centralized VCS like Subversion is stupid. But if you're a developer on a project where all the developers are in a common location sharing common infrastructure, often literally within speaking distance of each other, then a decentralized VCS like Git is stupid. It's harder to maintain and, in that situation, yields none of the offsetting benefits.
Analogy: a fleet of Chevy vans vs. a freight train. The vans are far more flexible, they can travel any route needed whereas the freight train's limited to fixed tracks, and their smaller size and lower cost each let you buy a lot of them and dedicate each one to just a few deliveries in a particular area without a lot of overhead. You can fan the vans out all over the city, sending just what you need where it's needed and rerouting each one to adapt to changes without upsetting the others. But if your only delivery each day is 1000 tons of a single product from one warehouse to another 600 miles away, you're better off with that one big freight train.
DVCS not inherently more difficult to learn (Score:2)
FUD. I think you may have had a bad experience with Git, which is known to be somewhat difficult to learn, but in general the easy things you do with a CVCS can just as easily be done with a DVCS (comm
Re: (Score:2)
Problem is, those "advantages" aren't in a lot of situations. Where I work, for instance, making it easy to get the code out of the office and onto a home machine would be a Bad Thing requiring nasty controls be imposed on the home machine to keep the code under the same control as if it were on the corporate internal network. Branching's already minimal-cost. The central repository's in the data center, and thinking is that if those machines are down then we're dead in the water anyway since our test envir
Re: (Score:2)
YOU STILL KEEP A SINGLE COPY OF YOUR DCVS ON YOUR MASTER SERVER. YOU STILL MAINTAIN CENTRALIZED CONTROL!
For example, look at Linux kernel development. Linus maintains the central repository. Every single other developer regularly syncs up with Linus while working on their own tree.
If you don't want people taking it home, then you tell them not to develop on their note books. Same as when you're using a CVCS.
DCVS still has a number of advantages:
1. It's dead simple to branch of
Re: (Score:2)
But if it's all on a centralized server, what does a DVCS give you that a CVCS doesn't?
1. It's dead simple to do this in CVS or SVN too. Branch, make your changes, check in as needed, merge when you're satisfied or discard the branch if you aren't. You don't need a DVCS for that. And yes, it gets stored forever. That's the point of a VCS. If it's your personal project it's not a big deal, but for corporate development the last thing you want is developers having work that's not available to everyone else.
Linus has a big mouth... (Score:5, Insightful)
Re:Linus has a big mouth... (Score:4, Insightful)
He's an excellent assembly hacker, a fast learner, and at least a majority of the time a nice guy, so most people overlook it.
Re: (Score:2)
Don't knock it till you try it (Score:5, Insightful)
Most of the people knocking DVCS or saying they can't see the benefits haven't actually used them on any projects. They have built up a framework in their minds of How Things Should Work, but unfortunately that model was defined by the limitations of their tools.
we use SVN (Score:5, Interesting)
SVN is currently integrated with our IDEs (all 3), one of the main selling points in choosing a VCS.
Ease of backups:
We archive our repositories every day, IT loves being able to simply tgz the SVN directory and not have to worry about anything else, regardless of the state of any current projects (all groups use SVN).
Simplicity:
SVN/Trac training (client use, management, backend workings) takes less than 10 minutes. In another 15 minutes I can have someone setting up their own SVN repositories+Trac, without needing to pull up a single reference document, primarily because the an SVN setup methodology is trivial to memorize.
Re: (Score:3, Informative)
I use Visual Studio with SVN at work, and while it doesn't have IDE integration (AnkSVN sucked last time I tried), which would be optimal, I find that using TortoiseSVN to be pretty adequate, if not better than IDE intergration in a lot of ways (Don't have to open the IDE to do an update on your local copy). I think the thing that makes both IDE integration and TortoiseSVN great is to be able to use a nice GUI to manage you checkins and updates. I mean, the command line works, but this
Re: (Score:3, Insightful)
Re: (Score:2, Informative)
> SVN is currently integrated with our IDEs (all 3), one of the main selling points in choosing a VCS.
Where I work we all use the cmdline, so IDE integration is a complete non-issue in selecting a SCM for some teams.
> IT loves being able to simply tgz the SVN directory
Pretty sure that's not the correct way to backup a Subversion repo, unless by 'simply' you mean that you first hot-backup.py the repo and then tar it up.
Re: (Score:2)
I actually don't know if the files are zipped since the size is not really an issue and I know I don't need anything other than an SVN directory (according to your naming conventions, as such):
svn/repositories
svn/conf
svn/tracenv
to completely restore all projects along with their Trac (given I have installed Trac), although I can simply rebuild Trac out of an existing repository anyways. We've never had trouble restoring. One of our younger r
SVN's weaknesses (Score:4, Interesting)
- Merges in a typical environment become effectively anonymous. Let's say you have a build manager and individual developers working on different changes in parallel. The build manager can't merge the changes without those changes taking on his identity, that is, all identifying information about the originator of the changes is lost.
- So-called "best practice" for SVN branching means building new branches with every new release. That is, it's not recommended to build one branch and merge changes from the trunk into it as you're incrementally changing things on that branch, noooo. You have to keep polluting the repository with needless hair by making new branches every week, and sometimes, multiple ones per day.
These are just two I'm aware of that bite us in the ass on a regular basis. The first issue is supposed to be fixed in one of the near-term mods to SVN, but the fact that the second even exists tells me that the guys developing SVN don't really work in the same world as a lot of the bigger commercial development environments do.Re:SVN's weaknesses (Score:5, Informative)
Since I'm sure you're not talking about what svn blame gives you, what do you mean exactly?
Umm, says who? Thanks exactly what we do. We have /trunk and /branches/devel. When one of us gets a particularly stable version of /branches/devel ready, we merge it to /trunk.
Have to? No way. But since branches are basically free, why would you want to avoid them?
We use them for experimental "what-if" branches, like "I wonder what would happen if I ported our application from MySQL to SQLite". You copy "/branches/devel" to "/branches/sqlite" and hack away. If it works, merge your changes back to devel. If it bombs, just delete the branch./P
Re: (Score:2)
The build manager can't merge the changes without those changes taking on his identity, that is, all identifying information about the originator of the changes is lost.
Since I'm sure you're not talking about what svn blame gives you, what do you mean exactly?
I think the parent is referring to the problem that when you merge, "svn blame" reports the merge itself as the origin of the changed lines rather than where they came from originally. It makes it difficult to know who really made those changes.
Re: (Score:2)
Why on Earth are you generating releases that often? I've worked in a lot of shops that used SVN, and at we used the SVN revision number for our "internal" releases. Given a path and a revision number, you have a unique identifier for *EVERY* sub-directory inside of an SVN repository. Until we actually made a long term supported branch we didn't bother with human consumable names.
If you really generate multiple branches a week inside of the same repository that you intend to provide long term support
My goal regarding the future of Subversion... (Score:4, Insightful)
Well if you're an MSDN developer... (Score:3, Informative)
If you're not an MSDN shop then what to use is more problematic. I really liked subversion but that was years back. From what I recall for what it was it does well. The only product I was ever "wow'ed" with was Accurev. That product deals with branching like a breeze and I think they might have a defect tracking module now.
Re: (Score:2)
from MS.com [microsoft.com]
Visual Studio Team System 2008 Development Edition
with MSDN Premium Subscription $5,469 $2,299
Don't forget that's $5k for the fist year, and then $2k per year renewal. It would be cheaper just to buy it, but then you'd not get the dev licences for the OS and other tools. shame really, MS used to be really good with these things but they've become too big, difficult to install, difficult to use and really expensive.
helloooo merge tracking (Score:5, Informative)
http://blogs.open.collab.net/svn/2007/09/what-subversion.html [collab.net]
BTW, they did a really nice job of mapping out the use cases and whatnot before implementing the feature. I guess source control people are natural planners.
http://subversion.tigris.org/merge-tracking/requirements.html [tigris.org]
Anyway, I'm sure the world will continue to have need for both distributed and client/server source control systems, and Subversion is a nice example of the latter.
Code integration assumptions (Score:4, Insightful)
Contrast this with a centralized source model where all developers have the ability to check in to the tree, optionally coupled with a peer review process, enforced either through convention or through mechanisms in the tools. Under this model each developer is responsible for their own integration and merging efforts, not wasting the time of a centralized authority. Not only is the central authority freed from routine tree maintenance work, but each developer can make the best and wisest decisions regarding the particular area of the codebase in which they are an expert, and not have to become involved in areas they have little experience with. Granted, for larger projects there is still a need for some management of checkin authorization, particularly to avoid conflicts during large tree merge operations and the like, but it's more of a coordination role than an authorization role.
This second model is what my employer uses, and our homegrown source control system is well-tailored to it (it actually has capabilities for more centralized control, but they are by and large unused). Perhaps this is unusual, as my experience with other employers is minimal, and mostly took the form of "copy your code into this directory once in a while" (i.e. "Source control? Why would we need that?"). However, given adequately diligent and intelligent developers, I have to say it works marvelously.
Re: (Score:3, Insightful)
What I don't see mentioned very often, if at all, is the implicit assumption in distributed systems such as git, that a single person has ultimate integration responsibility and authority in order to form the official/mainline release. That is, given a single tree that is considered the main one from which all others ultimately derive (Linus' tree in the Linux case), there is absolutely no way for tools such as git to allow collaborative maintenance of that tree. In the end, the owner of that tree must perform all checkins to the tree, and must resolve all merge conflicts themself. This is a dual problem in that it wastes the time of a potentially talented developer (e.g. Linus) doing the mundane work of merging and integration, and the additional problem that if this mainline tree owner is not an expert in some particular area of the code, they are likely to make mistakes when resolving conflicts or performing other integration tasks.
The reason you don't see it mentioned very often is because it's not really an issue. You just need that single person to be able to trust at least some of the developers they get changes from. Get the trusted "lieutenants" to do the merging for their particular areas. They can even delegate responsibility further. Since in a centralised system you have to trust all the developers to do merging this is no worse, and potentially better.
I happen to need a centralized version ... (Score:2)
... management system right now. One problem is, Subversion won't work because I need to have totally clean checkout trees. Subversion inserts tracking files in the checkout trees. So I guess I have to look for something else.
Re: (Score:3, Informative)
All version-control systems do that. It's not optional: you have to have meta-information about the checked-out files available, and there's no place in the files themselves to put that information. Now, you might want to look at the distinction between a working directory (with all the tracking files present, allowing the developer to check in and out, compare with different revisions in the tree, all the normal things) and an exported tree (created using for example the CVS "export" command, contains only
Re: (Score:2)
Re: (Score:2)
Problem: the VCS doesn't know the base of the project. If I'm editing a file in /home/me/src/projects/utilities/ljbackup/database, exactly what portion of that path is this project's tree and which is the part the project lives under? It has to be able to figure that out with nothing more than the path available, remember, since you don't want it to store anything in the working directory indicating what the base for this directory's files is supposed to be. And it also has to accept ljbackup/database being
Re: (Score:2)
It would be possible to make a means to discover where the base is without the need to have something inside the tree. You start by having a parallel tree with the meta data over there. Of course you have to know where that parallel tree begins, and there could be many schemes to find it. One is to have a specific name somewhere along the path to the current directory. That specific name is not the project base; it's just how to jump over to the parallel tree. Then from there the same relative path ha
Re: (Score:2)
Problem: the VCS doesn't know the base of the project. If I'm editing a file in /home/me/src/projects/utilities/ljbackup/database, exactly what portion of that path is this project's tree and which is the part the project lives under?
IIRC, some VCSs know. When you do a checkout, they store the path where you issued that command in a cache, which can be found relative to $HOME, not $CWD. Hmmm, it's been over a year since I last used it, but the more I think about it, the more I think that rPath's Conary works this way.
Why do you need a working directory without meta-data present? I can't think of too many reasons, and the ones I can think of fall under "That's probably a bad idea.".
Did you even bother to read the entirety of my reply? I said, "The MacOS programs Keynote and Pages pro-actively remove .svn (and other) directories when they find them." In other words, you have some Keynote objects;
Re: (Score:2)
This is what I had in mind. I didn't say we can't have any meta info at all. Instead, I just want the tree itself to be completely clean, and hold the meta info somewhere else, such as another parallel tree. And it could be made easy enough to find it with a simple rule: search up the path of parent directories until a directory with a specific name (such as ".svn-meta" as in your example) is found. It might usually be placed in the user home directory. It would apply to all projects that have differen
Re: (Score:2)
All version-control systems do that.
I know for sure that Clearcase doesn't do the equivalent of putting .svn directories all over the freaking place. There's a directory of tracking files at the checkout root, and that's it. And though it's been a while since I've used CVS, I don't remember CVS spamming control files all over the place like that either.
In fact, I'd have to say that all the .svn directory spam is probably the most annoying thing to me about svn.
Re: (Score:2)
(I'm looking at CVS on a Windows system and SVN on a Unix system, so the CVS name used under Unix or the SVN name used under Windows may be slightly different, but the directories are definitely there.)
Re: (Score:2)
Re: (Score:2)
Is that supposed to be a pun :-)
I guess you mean this project [bestpractical.com]. That does look interesting. Thanks!
Re: (Score:2)
Re: (Score:2)
If you're trying to do something like track configuration changes to a Linux server (such as monitoring
Distributed Systems Can Be Centralized (Score:2)
move to distributed (Score:2)
If Subversion doesn't move to a distributed model, I'm probably going to switch my projects incrementally over to Mercurial (Git isn't really an option).
Git and Mercurial are interesting ideas (Score:2)
Mercurial and get are mostly built around the model of sending your patches in via email. They make some noise about how you *could* build a central repository, but it's not like that out of the box, and things like permissions often aren't there yet.
Basically, the development