The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community. A number of feature enhancements, the most notable of which is support for locking are to be found on version 1.2.
Subversion 1.2.0 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Here’s a link to the release notes.
http://subversion.tigris.org/svn_1.2_releasenotes.html
Full WebDAV/DeltaAV support with autoversioning.
Better delta compression.
http://subversion.tigris.org/svn_1.2_releasenotes.html
It’s made my life so much easier… definitely a believer, and locking is only going to make it much better…
Two links;
http://toykeeper.net/tutorials/svnhome
http://www.onlamp.com/pub/a/onlamp/2005/01/06/svn_homedir.html
“I keep my life in a Subversion repository. For the past five years, I’ve checked every file I’ve created and worked on, every email I’ve sent or received, and every config file I’ve tweaked into revision control.”
Any additional comments or other links folks would like to share?
Personally I think that i’ll stick with the 1.1.x series as I value stability over features.
Anyone know what the new features are?
posted above…
to my knowlege…
locking
automatic webdav versioning (which is great if you want to have versioned remote folders)
better delta compression algorithms
fsfs is now the default repository type
performance improvements
bugfixes
anybody knows if svn plan to support Changesets feature anytime soon?
Man, I thought I was crazy when it came to preserve old things from a long time back. Maybe I’m just lucky, but I’ve managed to keep most of my stuff from the first computer I ever had. Doing manual backups now and then has done the job for me, quite nicely. I don’t see much benefit in bothering subversion with tons of homedir stuff, except perhaps for host-syncing. But for that I have my own nice and configurable rsync wrapper written in Python and PyGTK. I guess `svn up $HOME’ is not for me.
anybody knows if svn plan to support Changesets feature anytime soon?
Depends on what you mean by changesets. Right now commits are done atomically and revision numbers are repository wide, not per file. So, conceptually that’s a changeset right there because you can always see all of the changes that happend in commit #120, for example. Or is that not what you mean by changesets.
I believe that fsfs has been made default in svn somewhere in between 1.1.3 and 1.1.4 (I may be wrong).
I have had too many problems with BerkleyDB that I sticked with FileSystem and everything has been running smoothly
I just hope that upgrading to 1.2.0 is not a pain ….
I correct myself. Werner was right, fsfs has been made defult in this release.
Here’s the FULL changelog:
http://svn.collab.net/repos/svn/trunk/CHANGES
Version 1.2 brings over 50 bugfixes.
The biggest new feature is the optional ability to lock a file (like Visual SourceSafe). I don’t intend to use this new feature but it might be important for new users who do version control in such an outdated manner.
I’ll probably upgrade when 1.2.1 comes out. Version 1.1.4 has been rock solid.
Depends on what you mean by changesets. Right now commits are done atomically and revision numbers are repository wide, not per file. So, conceptually that’s a changeset right there because you can always see all of the changes that happend in commit #120, for example. Or is that not what you mean by changesets.
How about ChangeSet like what is present in BK, which consists of several files changed for 1 feature?
Thanks.
How about ChangeSet like what is present in BK, which consists of several files changed for 1 feature?
Short answer, yes it supports that. Here is the FAQ entry regarding it: http://subversion.tigris.org/faq.html#changesets
Actually locking, is sort of useless on code, but it is very useful if you work on binary files, where a visual merge is close to impossible in case of a conflict.
I am glad they did it and did not enforce it, you can always break the lock if you intend do, which prevents the worst misuses of the locking feature I have seen in the past with VSS.
Ever tried building it on all
the various operating systems
out there? What about Interix,
aka Microsoft Services for Unix?
I’d rather use CVS – if no version
control system (even RCS) is
readily available, it’s got
the least effort to install it.
And GNU CVS 1.12.12 has some nice
features, with OpenCVS being
under active development and
bringing in a fresh breeze
(not now though).
>The biggest new feature is the optional ability to lock a
>file (like Visual SourceSafe). I don’t intend to use this new
>feature but it might be important for new users who do
>version control in such an outdated manner.
This is by all means not an outdated method.
It’s just a different development method, and it’s great having svn support that too.
Granted, for distributed developemnt on OSS projects, this is probably not great or much used.
In other development envirnonments it is – VSS or not.
Serves among others as a reminder that someone is working on this/that – don’t touch. And have you tried merging a Word document.
Point is the world is not hetrogenous, the purpose of a version control system is to help people with their development, not change their ways of develop methods.
>feature but it might be important for new users who do
>version control in such an outdated manner.
You have no idea what you’re talking about. Plain simple. Stop spreading FUD. A locking mechanism is sometimes needed and or desired. Period.
> Stop spreading FUD. A locking mechanism is sometimes
> needed and or desired. Period.
Whatever floats your boat. I don’t think it’s FUD to say that you won’t find a feature useful and hence won’t use it…
The Subversion website actually lists serveral cases where users will want locking. This primarily has to do with changes to binary files such as images, word-documents, resource files and so on.
One could argue, that if they allowed merge-tool plugins, it might be possible to graphically merge some binary files such as images or word document, but until that time comes, locking is going to be a necessity.
Why would you want to build Subversion on Unix for Windows when it builds nativly for Win32? If we can build Subversion on Syllable without patches, I fail to see how you could have much of a problem on anything vaguely POSIX compliant.
On another note I’ll push the 1.2.0 client out to my users due to the additional password cache encryption in the Win32 client. I’ll not upgrade the server side until I have a real need for locking. If we could easily migrate existing DB3 repositories to FSFS I’d be all over it though. I’m pretty bored of having to poor over my backup logs each night looking for repositories with broken locks to recover.
According to the Subversion site, they’ve already found and fixed some bugs. You’d be better off waiting for Subversion 1.2.1 before deploying it.
Personally, I’m also going to wait till TortoiseSVN catches up.
Should be fairly simple. Create the new repository, svnadmin dump the old one to a file, then svnadmin load the file to the new repository.
Locking is pretty useless for code, especially for large projects with lots of people (everything would be locked all the time) but if you want to have documents under revision control, it’s pretty handy.
The Subversion website actually lists serveral cases where users will
want locking. This primarily has to do with changes to binary files
such as images, word-documents, resource files and so on.
Oh, so you actually need locks?
In BSD land, developers just talk
to each other. Works surprisingly
well. Do you consider communication
an outdated version control helper
mechanism too?
Why would you want to build Subversion on Unix for Windows when it
builds nativly for Win32?
Because it integrates better into my work environment in
some cases? Because MirPorts bring Unix apps to SFU?
If we can build Subversion on Syllable
without patches, I fail to see how you could have much of a problem on
anything vaguely POSIX compliant.
Oh yeah, Subversion itself may be easy, but its zillion
of dependencies are NOT. Berkeley DB *shudder*.
And the APR is unfree.
Uh, what’s the point of a version control system if I have to email every developer in the building every time I change a file (and assume they read the email). Or do you propose I should walk around the building and speak to each of them personally?
Placing a lock on the file will inform anyone who cares that I am working on the file. It is a form of communication.
However the primary reason for source-control systems is to free each developer of the burden of having to discuss every change with all other developers on the project in advance. This is a significant time saving. Try working on any moderately complex project with more than five developers working at the same time and you’ll understand.
Right now however, you just don’t know what you’re talking about.
[And what the hell does BSD have to do with this]
I’m not saying that locks won’t be useful.
I’m sure that in large environments where there are (perhaps) thousands of developers using a single code tree, locking would be useful.
I just think it is an overreaction to say that because, I won’t find the feature particularly useful, that I am spreading FUD.
Other than that, subversion does the job.
I just think it is an overreaction to say that because, I won’t find the feature particularly useful, that I am spreading FUD.
But I wasn’t talking about you (I think). Sorry if you misunderstood. But saying that locking is NOT useful is FUD. It creates the idea that locking is BAD.
Anyone who says locking is bad, has never been involved in a med/complex project where there are people around the globe hitting the same tree.
I fail to see what has BSD got to do with this, but to that poster, I’ve got to say: mate, you haven’t got a clue…
This is not sourceforge where you have a devel mailing list and everything is discussed. Projects that aren’t open source (while this isn’t a req.) DO need locking, some teams are doing this, some other teams are doing that.
Get involved in something other than the “BSD” (??) team before attacking locking.
And on the other hand, IDEs like Visual Studio may touch and reorder the file content if you use the visual designer (blame Microsoft Corp.), thus creating hordes of Conflicts you have to hand merge. “Just because VS decided to move the same darn lines a few spaces”. (I’ve seen it) That’s why I use XCode 2.
I just think it is an overreaction to say that because, I won’t find the feature particularly useful, that I am spreading FUD.
But I wasn’t talking about you (I think). Sorry if you misunderstood. But saying that locking is NOT useful is FUD. It creates the idea that locking is BAD.
Anyone who says locking is bad, has never been involved in a med/complex project where there are people around the globe hitting the same tree.
I fail to see what has BSD got to do with this, but to that poster, I’ve got to say: mate, you haven’t got a clue…
This is not sourceforge where you have a devel mailing list and everything is discussed. Projects that aren’t open source (while this isn’t a req.) DO need locking, some teams are doing this, some other teams are doing that.
Get involved in something other than the “BSD” (??) team before attacking locking.
And on the other hand, IDEs like Visual Studio may touch and reorder the file content if you use the visual designer (blame Microsoft Corp.), thus creating hordes of Conflicts you have to hand merge. “Just because VS decided to move the same darn lines a few spaces”. (I’ve seen it) That’s why I use XCode 2.0 now.
Theoretically you aren’t allowed to post “too fast”, however, for some reason my post got duplicated “at once”. Sorry.