Recent Features
| |||||||||||||
A proposed Subversion vision and roadmapA proposed Subversion vision and roadmapPosted Apr 3, 2010 18:52 UTC (Sat) by dskoll (subscriber, #1630)Parent article: A proposed Subversion vision and roadmap
What's more, huge classes of users remain categorically opposed to the very tenets on which the DVCS systems are based. Well, time to educate them, then. They need centralization. No, they say they do. Or they think they do. But you can have an official "central" repo with any DVCS tool. They need control. They need meaningful path-based authorization. They need simplicity. In short, they desperately need Subversion. Meh. FUD.
(Log in to post comments)
A proposed Subversion vision and roadmap Posted Apr 3, 2010 20:42 UTC (Sat) by marduk (subscriber, #3831) [Link]
Pony: I don't need a motorcyle. I need my airplane. You see I fly back and forth to Chicago and...
Pasty: No! You see you're thinking about it all wrong. A motorcyle is more than just a 2-wheeled motor bike. It's a transportation framework. You can easily change and augment it. You can add wings and rudders. A bigger fuel tank. A bigger engine! More storage compartments. Even a side car for additional passengers. You see with a motorcyle you can do anything you can do with an airplane, and more. All you have to do is change your mindset and spend a bit more time and money and you can fly to Chicago on a motorcyle.
Pony: Yeah, or I can just keep my airplane.
A proposed Subversion vision and roadmap Posted Apr 4, 2010 6:30 UTC (Sun) by flewellyn (subscriber, #5047) [Link]
Good analogy, except that SVN is like the motorcycle here.
A proposed Subversion vision and roadmap Posted Apr 3, 2010 20:55 UTC (Sat) by MisterIO (guest, #36192) [Link]
Educate them?! Why? Do they want to use Subversion or any other non DVCS? Fine, let them do that! Sometimes it may not even be a technical problem at all; it may just be their taste or it's just that they simply don't need anything more than what they already have. Either way, DVCS are out there, so if they need them, they're gonna use them sooner or later, but they certainly don't need to be educated.
A proposed Subversion vision and roadmap Posted Apr 4, 2010 0:09 UTC (Sun) by dskoll (subscriber, #1630) [Link] Sometimes it may not even be a technical problem at all; it may just be their taste or it's just that they simply don't need anything more than what they already have. Absolutely 100% agreed. And if the SVN developers came out and said "Subversion is for those people who like Subversion, or for whom it's adequate, or who don't want to learn another system", great! But spreading FUD by saying you need this, that or the other feature that only SVN has is simply.. FUD. SVN definitely has its place. While my workplace has switched to git for source-code control, we still use SVN to manage document revisions for non-technical personnel. We found they took a while to wrap their heads around "update" and "commit", and certainly didn't think they'd easily grasp "commit" vs "push", and "fetch"/"pull"/"merge".
A proposed Subversion vision and roadmap Posted Apr 4, 2010 9:50 UTC (Sun) by epa (subscriber, #39769) [Link]
Agreed. There are just too many stages in 'saving a file' for nontechnical users to easily grasp Git.
When we first start using a computer we soon learn that what we see on screen is not permanent
Surely all this could be simplified a little?
A proposed Subversion vision and roadmap Posted Apr 5, 2010 12:25 UTC (Mon) by efexis (guest, #26355) [Link]
Inotify! With Linux::Inotify2 for Perl and shell based stuff like inotifyd (and other language equivs), scripting those kinds of things to happen automatically on a Linux system becomes pretty easy; you can just have the commit stages (I presume, I've not used git myself yet) on file update detection. I often use it for clients who run Windows, connecting to Linux system running Samba. They drag a file into a specific shared directory, upon the fclose event my code kicks in, processes it, spits them back out the processed result. I don't have to write any kind of interface, they don't have to learn one, I love it, has the potential to be my hammer-for-everything though so don't be surprised if it's not helpful here!
A proposed Subversion vision and roadmap Posted Apr 7, 2010 20:43 UTC (Wed) by vonbrand (subscriber, #4458) [Link] One git frontend which tried to hide the index was cogito, currently deprecated. At first, it was confusing to have to consider the index at all. Nowadays I mostly forget about it, but when I need it it is extremely handy.
A proposed Subversion vision and roadmap Posted Apr 5, 2010 3:39 UTC (Mon) by martinfick (subscriber, #4455) [Link]
FUD = "Fear, Uncertainty and Doubt", please explain where any of those 3
things are being used? While, you may not agree with the SVN developers' comments, or even think they are untrue. I just can't see how you can claim FUD spreading here?
A proposed Subversion vision and roadmap Posted Apr 5, 2010 12:36 UTC (Mon) by efexis (guest, #26355) [Link]
Consider "Those who become obsessed by the enemy become the enemy" where 'the enemy' = FUD and the spreading of. To me it read like SVN devs here are saying they are aware of and respect the offerings of the other tools that cover DVCS functionality and aren't wanting to step on anybody's toes. As with anything with multiple potential solutions, each one slightly different and catering to slightly different needs or tastes, you'll always get people religiously telling why their way is The True Way(tm) ... even after saying this same thing to somebody else earlier today on a different subject, it still takes me a little by surprise quite the level of it on this page. It's software, it's a tool, it really shouldn't evoke this much emotion!
A proposed Subversion vision and roadmap Posted Apr 3, 2010 22:30 UTC (Sat) by cbcbcb (guest, #10350) [Link]
Advantages of svn in a corporate environment:
1. A central server is required as the one which is stored on fully backed up storage. (yeah yeah, DVCS means there's a copy on everybody's desktop. All in the same building. Real backups are off site)
2. developers can't make a mess of the repository metadata. (On lkml Linus sometimes tells developers that he won't pull because the history is in a mess - but without a single gatekeeper you can't assume that none of the developers with commit rights won't introduce such a mess)
3. Svn authentication is delagated to the owners of the repository, it doesn't require sysadmins to get involved tweaking UNIX groups.
4. Svn provides the means to automatically check commits on the server, so eg all commit messages have a bug tracking number, changes conform to the coding standard, whatever)
5. Svn works properly on windows.
6. Svn can represent empty directories. AFAIK git can't.
It's nothing fundamental, but calling FUD and trying to tell svn users that the svn features they use and git/hg/bzr/etc don't have are useless is a waste of everybody's time. It would be great if somebody could set up the tools to support a corporate environment while also exploiting the advantages of a dvcs
A proposed Subversion vision and roadmap Posted Apr 3, 2010 23:44 UTC (Sat) by marcH (subscriber, #57642) [Link]
> 1. DVCS means there's a copy on everybody's desktop. All in the same building.
No.
> 2. developers can't make a mess of the repository metadata.
Care to elaborate? I've seen interesting screw-ups of SVN repositories. Inconsiderate developers will screw-up anything. This depends on the workflow not on the tool(s).
> 3. Svn authentication is delagated to the owners of the repository, it doesn't require sysadmins to get involved tweaking UNIX groups.
I am afraid this is your only point. I am not sure how convenient it is to emulate SVN's authentication model with the various DVCS out there.
> 4. Svn provides the means to automatically check commits on the server,
Come on, any system has hooks.
> 5. Svn works properly on windows.
Git is not the only DVCS.
> 6. Svn can represent empty directories. AFAIK git can't.
I'm really impressed. Use a hidden file?
> trying to tell svn users that the svn features they use and git/hg/bzr/etc don't have are useless is a waste of everybody's time.
It would be but I seldom hear this. What I most often hear and read and see is how DVCS offer 99% of SVN's features (and more).
> It would be great if somebody could set up the tools to support a corporate environment while also exploiting the advantages of a dvcs
Agreed.
A proposed Subversion vision and roadmap Posted Apr 5, 2010 15:34 UTC (Mon) by bronson (subscriber, #4806) [Link]
>> trying to tell svn users that the svn features they use and git/hg/bzr/etc don't have are useless is a waste of everybody's time.
>It would be but I seldom hear this.
You said it yourself. Check out your snide reply to #6.
A proposed Subversion vision and roadmap Posted Apr 4, 2010 6:05 UTC (Sun) by emk (guest, #1128) [Link] 1. A central server is required as the one which is stored on fully backed up storage. (yeah yeah, DVCS means there's a copy on everybody's desktop. All in the same building. Real backups are off site) I've managed offsite backups for both Subversion and git, for repositories in the 320GB range. In my experience, reliable Subversion backups require a script to hotcopy the entire repository, and a fresh whole-repository backup using a full-fledged backup system. This tends to cause minor headaches for incremental backup systems. Git, in contrast, can do very fast incremental backups via cron and git pull. Even better, it can trivially verify the integrity of a repository by checking all the hash sums. Now, there are drawbacks to using git for certain kinds of large organizations. Git submodule support, for example, is pretty arcane and requires a moderate level of git-fu. But from a backup perspective, I'd rather use git than subversion any day of the week.
A proposed Subversion vision and roadmap Posted Apr 4, 2010 9:53 UTC (Sun) by epa (subscriber, #39769) [Link]
The recommended way to back up an svn repository is with 'svnadmin dump'.
Are you saying this doesn't work reliably?
A proposed Subversion vision and roadmap Posted Apr 5, 2010 14:51 UTC (Mon) by Thalience (subscriber, #4217) [Link]
I'm pretty sure the charge is that using "svn dump" in this way is slow, and a (minor) hassle to set up.
A proposed Subversion vision and roadmap Posted Apr 5, 2010 17:45 UTC (Mon) by emk (guest, #1128) [Link]
svnadmin dump requires a complete copy of the entire repository in each
daily backup. (And, IIRC, dumps are frequently larger than the original repository.) Once repositories reach a certain minimum size, this adds considerably overhead to daily incremental backups.
svnadmin hotcopy produces an exact copy of the repository. If you're
git backups require a 1-line cron job that calls 'git fetch', and generally
So given a choice, I'd _much_ rather manage backups for a git server than
A proposed Subversion vision and roadmap Posted Apr 4, 2010 11:43 UTC (Sun) by fperrin (guest, #61941) [Link]
> Advantages of svn in a corporate environment:
Further advantages :
- SVN works through a HTTP proxy. Last I checked, it was possible to do that in git, but the
- in SVN, you can checkout just a subdir of the repo. This is (part of) what made the switch of
- SVN works and is actively used on Windows. According to WP, git uses either cygwin, or a
A proposed Subversion vision and roadmap Posted Apr 4, 2010 20:57 UTC (Sun) by nix (subscriber, #2304) [Link]
GNOME's switch to git was a disaster? Sorry, I hadn't noticed. I was too
busy celebrating the convenience of being able to version-control my local changes.
(And, honestly, which subdir of which GNOME app do you want to check out?
A proposed Subversion vision and roadmap Posted Apr 4, 2010 22:14 UTC (Sun) by fperrin (guest, #61941) [Link] Not being a GNOME contributor, I must say that I got only one side of the story, that is, fpeter's one. The conversion itself was rather painful, but not because of git per se. However, a lot of translators are from countries were Internet access is quite slow ; they used to checkout only the po subdirs of applications, which they can no longer do. Since in the month before each release, translations represent about half the activity of GNOME's SVN repo, that's quite a problem for GNOME. In addition, while looking for some references, I just found a recent example were patches are not committed because the committer doesn't have a big enough HDD to checkout the entire module. This wouldn't happen if git was able to checkout only the concerned subdir... NB: I'm not a SVN fanatic; it's just that I want to counter the opinion of the majority in this discussion which seems to be, with a couple of exceptions, that SVN sucks and git is the alpha and the omega. git is good, SVN has flaws, and vice-versa.
A proposed Subversion vision and roadmap Posted Apr 5, 2010 0:41 UTC (Mon) by tzafrir (subscriber, #11501) [Link]
I read through that presentation, and it mostly makes the point that the migration wasn't easy. That's something you would expect.
For instance, why would you automatically convert the svn:ignore property to a per-directory .gitignore? You can do that (.gitignore can be on every directory, but it can be on every directory above it).
It does not really state the other points that he attempted to show.
And maybe translators just don't need to deal with the version-control system directly. If translators didn't check-out the whole application, they probably never really used it as proper version control: they never really tested their translation with the latest "SVN build". So maybe translators should switch to something like Transifex.
A proposed Subversion vision and roadmap Posted Apr 6, 2010 16:40 UTC (Tue) by Spudd86 (guest, #51683) [Link]
"So maybe translators should switch to something like Transifex."
This seems to be exactly what they are doing. (I read planet Gnome, I vaguely recall some mentions of new tools for translators and workflow improvements for them, I don't recall clearly because I don't particularly care about translation workflows)
A proposed Subversion vision and roadmap Posted Apr 5, 2010 0:47 UTC (Mon) by cesarb (subscriber, #6266) [Link]
> This wouldn't happen if git was able to checkout only the concerned subdir...
Now it can, with the "sparse checkout" feature in 1.7.0. Combine it with a shallow clone, and you can use a lot less disk space.
A proposed Subversion vision and roadmap Posted Apr 5, 2010 7:01 UTC (Mon) by shmget (subscriber, #58347) [Link]
"SVN works and is actively used on Windows. According to WP, git uses either cygwin, or a
testing version running msys that doesn't seem very stable."
If stability was your concern you wouldn't be using Windows to start with.
A proposed Subversion vision and roadmap Posted Apr 5, 2010 16:36 UTC (Mon) by cortana (subscriber, #24596) [Link]
Please, no more snide remarks.
Many of us use Windows for our day job, and work on a variety of projects with different version
I don't think anyone could honestly state that the Windows port of git is as polished as its
A proposed Subversion vision and roadmap Posted Apr 6, 2010 16:48 UTC (Tue) by Spudd86 (guest, #51683) [Link]
The main issue I've had using git on windows has been line endings and filename case, both confuse git into thinking a file in my working copy is different from the HEAD when in fact it is not, and trying to do a commit confuses git. (Filename case confuses it during checkout, if the file has the name "Foo.c" in the working copy for some strange reason, while git thinks of it as being foo.c it will be confused... I'm not actually sure how I got into that situation...)
The line ending issue is avoidable by just turning off line ending conversion entirely and using a text editor other than Notepad.
The second is a result of Windows breaking an assumption git makes about file names, and really Windows' case insensitive file names are a pain to deal with in a portable way... you pretty much have to write a crapload of code twice...
A proposed Subversion vision and roadmap Posted Apr 6, 2010 20:25 UTC (Tue) by vonbrand (subscriber, #4458) [Link] What you describe is the mess caused by Windows and Unix using different line ending conventions. It bites you everywhere...
A proposed Subversion vision and roadmap Posted Apr 6, 2010 23:07 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
git supports work-arounds for both of these problems
you can tell git to change the line ending when a file is checked in, checked out, both, or neither. you can modify this by editing the git config file or useing the git config command.
you can tell git what to do about case sensitivity (although I don't remember the details of how to set this.
A proposed Subversion vision and roadmap Posted Apr 8, 2010 16:30 UTC (Thu) by Spudd86 (guest, #51683) [Link]
I'm aware that I can tell git to do line ending conversion, however the case sensitivity thing was basically git thought it had a file Foo.txt that was untracked and a file foo.txt that was, then when I try to do some things git refuses to do it because it thinks it's about to blow away something... (ie checkout a new file on top of an untracked one)
A proposed Subversion vision and roadmap Posted Apr 8, 2010 18:19 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
I believe that you can set case sensitivity as well. There has definitely been a lot of discussion on the subject and how to deal with it. I just don't remember how to configure it.
A proposed Subversion vision and roadmap Posted Apr 6, 2010 20:24 UTC (Tue) by vonbrand (subscriber, #4458) [Link] AFAIU, the (dumb) HTTP transport for git justgets each object as a separate file, precisely so that no "smart" HTTP tool on the path messes up the communication. It is slow as molasses in winter, but should work everywhere. There isn't any "pages long setup" for this on the server either...
A proposed Subversion vision and roadmap Posted Apr 8, 2010 2:12 UTC (Thu) by smurf (subscriber, #17840) [Link]
> GETting each separate file
That happens if you intentionally never repack your archive and never update the index file. Not a problem in real life, at least not for initially cloning an archive.
|
|||||||||||||