Subversion 1.8.0 released
the most popular and widely-used Open Source version control system" — Subversion 1.8.0. "
Since their introduction in prior releases, Subversion’s merge tracking and tree conflict detection features have been critical to its ability to serve projects where branching and merging happens often. The 1.8.0 version improves these features, further automating the client-side merge functionality and improving both tree conflict detection during merge operations and tree conflict resolution during update operations. Additionally, the Subversion client now tracks moves of working copy items as first-class operations, which brings immediate benefit to users today and is a key step toward more thorough system-wide support for moved and renamed objects in a future release."
Posted Jun 18, 2013 13:47 UTC (Tue)
by simlo (guest, #10866)
[Link] (60 responses)
There seems to be an agreement to move to Git now. Is there any argument to keep Subversion instead of switching to Git?
Posted Jun 18, 2013 13:56 UTC (Tue)
by ovitters (guest, #27950)
[Link]
Posted Jun 18, 2013 13:59 UTC (Tue)
by dskoll (subscriber, #1630)
[Link] (32 responses)
Is there any argument to keep Subversion instead of switching to Git?
For technical users, I don't think so. For less technical users,
maybe: Here at work, we keep all our documents in Subversion because I
believe the non-technical staff find it much easier to grasp than they
would Git, and the RapidSVN GUI is fairly reasonable.
I use "git svn" to interact with the SVN repo which gives me the best of
both worlds.
Posted Jun 18, 2013 14:27 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (13 responses)
Is mercurial's user interface actually simple enough to understand for non-technical users? That could be the best of both worlds. Almost.
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-...
Posted Jun 19, 2013 3:40 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
That depends. How many commits are in the SVN repo? If it's a large repo, it's best to do the conversion once and then use that if you have multiple people working on it. If two people use different flags for "git svn clone", the repos are basically incompatible.
Posted Jun 19, 2013 14:42 UTC (Wed)
by dgm (subscriber, #49227)
[Link] (2 responses)
That should be no problem, as long as they use git as a SVN client. That means that the canonical repo is still the SVN one, so they only need to be compatible with SVN, not between them.
The nice thing is that they can still clone and fork each other repos, push stuff around and it will commit to SVN just fine. It's magic, if you ask me.
Posted Jun 20, 2013 0:36 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Jun 23, 2013 22:34 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
It is still better than the native SVN client.
Posted Jun 20, 2013 16:54 UTC (Thu)
by khim (subscriber, #9252)
[Link] (8 responses)
Posted Jun 22, 2013 15:31 UTC (Sat)
by dskoll (subscriber, #1630)
[Link] (2 responses)
If you use git-svn then you make life of all your coworkers miserable:
Not at all. Recall how I'm using SVN: as a repository for non-technical people to check in documents and have them in centralized version control. We're not using any of the advanced features of SVN and none of my coworkers even notices that I use git svn instead of svn directly.
Posted Jun 24, 2013 21:31 UTC (Mon)
by khim (subscriber, #9252)
[Link] (1 responses)
You mean they don't need to know about histories of their files? Why are you using such a complex tools as SVN, GIT, etc? Simple network share should suffice. GIT-SVN is fundamentally incapable of keeping correct SVN history (just a recent example). Worse: it usually works and it's very easy not to notice a problem when you commit your file. But later, when you'll try to use SVN for the forensic work (this is what VCS is used for, right?) you'll find out that history of your project is scrambled up. Sure. For them the end result looks like a work of madman who copies files around randomly and changes them for no apparent reason. You can create something like this with SVN client, obviously, but in that case history is usually looks saner.
Posted Jun 25, 2013 7:48 UTC (Tue)
by marcH (subscriber, #57642)
[Link]
Even if *they* don't want to know, other people like him probably do.
It's quite frequent to have to force "non-technical" people to use version control. Worse, you'll even find some people still refusing to see the value of it even after using it for a long time.
Git is the very last solution you want to this type of problem.
Posted Jun 23, 2013 22:32 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (4 responses)
In practice I've never seen anyone using git-svn getting noticed.
Yes I remember myself temporarily switching to the native SVN client to operate on SVN properties. However I never broke any with git-svn.
Maybe someone tried to blame the tool for his own mistakes?
Posted Jun 24, 2013 21:19 UTC (Mon)
by khim (subscriber, #9252)
[Link] (3 responses)
Of course not! Other people notice problems, not git users! Just a recent example of this fundamental problem. Unfortunately one of these "SVN properties" is information about history of a particular file. And if you don't need to know about different versions of your file then why are you using VCS in the first place?
Posted Jun 25, 2013 7:59 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (2 responses)
In practice I've never seen anyone using git-svn getting noticed by *SVN users*.
Your "recent example" link does not look related, did you copy the wrong URL?
In another post you seem to hint at file renames in a roundabout way. I would certainly avoid git-svn and switch back to a plain SVN client if I were to rename files "like a madman".
[In fact I avoid "madman renames" at all cost - with any client. Even when renames are tracked in the best possible way they *always* create pain no matter what]
> And if you don't need to know about different versions of your file then why are you using VCS in the first place?
Thanks for keeping the signal/noise ratio of this thread higher than this.
Posted Jun 25, 2013 15:50 UTC (Tue)
by nye (subscriber, #51576)
[Link] (1 responses)
I see what khim means:
That thread describes an example where a file has been mostly rewritten, and the new file is almost identical to an unrelated file elsewhere in the tree, because they are both so short that the license header constitutes the majority of the file.
Since git tracks the state of trees, there's no problem when you're using git natively. To send the changes to svn though requires that git generates a diff. The change to the file is so great, and the similarity to an existing file so high, that the diff it generates by default describes a copy of the other file followed by a change of the non-license part of the file, which is clearly a failure in git's move/copy detection heuristics and will produce nonsensical change history when imported to svn.
That said, it's arguably not too major a failure, because if you're looking at the diffs you're generating then you can see the problem immediately and can ask git to DTRT by setting the similarity parameter for the heuristic to something more appropriate. I don't know if git-svn makes that easy to notice in the standard workflow though, as I don't use it.
There are some fairly dodgy heuristics in git which can cause this kind of thing, and while we're looking at dodgy heuristics I might suggest that the similarity threshold could be a) dynamically adjusted according to the length of the file, and b) possibly altered to weight lines more heavily the further they are down the file, based on the reasoning that it's typically the beginning of most files (for code anyway) that tend to have a load of common guff that confuses the similarity detection.
Posted Jun 27, 2013 22:12 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
Clearly the type of thing that happens everyday at the git-svn office.
Once again and more seriously: every single limitation of git-svn can quickly be worked around by temporarily (and rarely) switching back to the plain SVN client.
Posted Jun 18, 2013 14:33 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (17 responses)
> For technical users, I don't think so.
It really depends what meaning you give to "technical user". I've been supporting a large team that absolutely everyone would call "technical" yet it made me realize how:
1. How the git _user interface_ has obviously grown organically, is inconsistent and lacking any design vision (see link above).
Point 2. is wrong and should not happen but what you can you do about it? Not much except use something simpler than git, at least superficially.
Posted Jun 18, 2013 14:52 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (15 responses)
Mercurial does most of what Git does and is arguably a lot more straightforward to get to grips with.
Posted Jun 21, 2013 13:21 UTC (Fri)
by robert_s (subscriber, #42402)
[Link] (14 responses)
Posted Jun 21, 2013 14:05 UTC (Fri)
by dark (guest, #8483)
[Link] (1 responses)
Posted Jun 23, 2013 22:27 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
For the last few years I also found it always easy to recover from the messes my colleagues regularly did. Too bad I was the only one.
Posted Jun 22, 2013 12:52 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (11 responses)
Posted Jun 22, 2013 21:08 UTC (Sat)
by jimparis (guest, #38647)
[Link] (8 responses)
"git checkout" is a particularly easy to way lose data. It will either switch branches, or clobber uncommitted working changes, depending on how badly you mistype or get confused. Oops!
Posted Jun 23, 2013 1:27 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (7 responses)
Posted Jun 23, 2013 2:03 UTC (Sun)
by jimparis (guest, #38647)
[Link] (6 responses)
No, I'm referring to running git checkout file when file has unstaged changes. Git irrevocably clobbers file with the original copy without confirmation. And that is made significantly worse by the fact that git checkout branch is a common non-destructive operation. It means that a small brain fart while trying to do something non-destructive (checkout a branch) can easily destroy data (checkout a file).
Posted Jun 23, 2013 4:09 UTC (Sun)
by jedbrown (subscriber, #49919)
[Link] (5 responses)
Posted Jun 23, 2013 6:15 UTC (Sun)
by dlang (guest, #313)
[Link] (3 responses)
picking on git for doing so seems odd.
Posted Jun 23, 2013 17:21 UTC (Sun)
by jimparis (guest, #38647)
[Link]
picking on git for doing so seems odd.
Say you have two branches with an identical file. You edit the file,
then realize you wanted to commit to the other branch. So you might
do this, which is fine:
Posted Jun 23, 2013 22:23 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
None. This is about the one that makes it the easiest.
Posted Jun 24, 2013 9:38 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
"git checkout" is really one of the dumbest ideas in Git.
Posted Jun 23, 2013 10:29 UTC (Sun)
by dark (guest, #8483)
[Link]
Posted Jun 18, 2013 18:37 UTC (Tue)
by dskoll (subscriber, #1630)
[Link]
Well, let me clarify. I didn't think our non-technical users would easily grasp the concepts of distributed version control, whereas they understand the centralized model pretty easily.
I have not used Mercurial, so I can't comment on its interface. I do find git hard to use, inconsistent and (to be honest) inscrutable at times. It's just so darn powerful, fast and widely-used that we've standardized on it.
Posted Jun 18, 2013 14:03 UTC (Tue)
by pabs (subscriber, #43278)
[Link] (4 responses)
Posted Jun 18, 2013 22:39 UTC (Tue)
by debacle (subscriber, #7114)
[Link] (3 responses)
Or one want only the top-level directory of a project and selected sub-dirs. Again, no problem with SVN (--depth, --set-depth etc.), but impossible with git, to my (limited) knowledge.
Posted Jun 19, 2013 3:30 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Jun 22, 2013 15:10 UTC (Sat)
by zack (subscriber, #7062)
[Link] (1 responses)
Has this happened already? It's been on the roadmap for quite a while, but I don't think it actually has. At least, quick checking on the git submodule manpage and on the Git book seems to still claim that submodule can only track specific commits. If anyone has evidence to the contrary, I'd love to stand corrected (and start using the new feature, I really can't wait for it!)
Posted Jun 23, 2013 15:52 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Flag to `add`:
> -b, --branch
Flag to `update`:
> --remote
Posted Jun 18, 2013 14:29 UTC (Tue)
by jreiser (subscriber, #11027)
[Link] (4 responses)
Single elements that are longer than 2**31 or 2**32 bytes may be troublesome.
If ever there is a hash collision then git is broken, including the possibility of generating garbage silently. Literal examples of MD5 collisions (128 bits) on short inputs have been exhibited. sha1 collisions (160 bits, used by git) are rarer.
Posted Jun 18, 2013 14:51 UTC (Tue)
by tialaramex (subscriber, #21167)
[Link]
The best presently known attack against SHA-1 is around 2^61 with practical execution time of some days and requiring a substantial (millions of dollars per attack) investment. Of course such attacks never get worse, only better and so it's reasonable to plan ahead, but my impression is that dropping in a new hash is considered practical, were the need to arise.
If you aren't trying (and you're not giving access to an adversary who you believe might be trying) to break the hash then you've nothing to worry about, natural collisions are ridiculously unlikely, by the birthday paradox you'd expect to see one after injecting about a million billion billion objects. Corruption introduced by disk faults, RAM ECC failures, and so on are probably more likely. Also you'll probably run into a horrible scalability problem by then.
Posted Jun 18, 2013 19:09 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
Ever the engineer, Linus reaction was as another poster said, and he thought the chance wasn't worth allowing for. But it's a risk that must be trapped.
So I don't think git will corrupt your project silently. Instead, the commit will fail rather noisily.
Cheers,
Posted Jun 18, 2013 21:08 UTC (Tue)
by marcH (subscriber, #57642)
[Link]
I guess everything is covered in just one line of code?
Posted Jun 19, 2013 19:02 UTC (Wed)
by intgr (subscriber, #39733)
[Link]
If by "rarer" you mean "someone made a tremendous breakthrough in cryptanalysis", then yes. The chances of it "breaking git" by accident is statistically impossible. You're more likely to win the lottery, several times in a row, without buying a ticket.
Even with MD5, a simple prefix collision attack would be rather difficult to abuse. I can imagine just one scenario: You'd have to get a malicious patch into git, containing some specially computed random-looking garbage. And then get direct write access to the base repository, to swap out that data with a malicious replacement. People who cloned the repository in the past will have the old data, people who will clone it in the future will have the new malicious payload and git won't be able to tell the difference.
It could be that there are other scenarios -- I'd be interested to hear.
Posted Jun 18, 2013 16:06 UTC (Tue)
by epa (subscriber, #39769)
[Link]
Posted Jun 18, 2013 18:54 UTC (Tue)
by imz (guest, #74088)
[Link] (11 responses)
An argument that made me recently consider other VCSs (than Git):
Git on Windows appears to be very unstable.
My recent problem: https://github.com/msysgit/msysgit/issues/123 .
I gave Git to a "non-technical" person who uses Windows. We happily worked together with him remotely editing a book.
Then after less than a week his Git didn't work anymore! He could read that there happened "error 487" when he tried to commit as usual through the GUI.
We must arrange for another meeting in real life so that I can either try to find out the details of the problem with Git and fix it, or install and teach him another VCS.
There are often cases when I'd like to work together with people who use Windows, and I want to suggest them to use a VCS. Ok, now, I see that Git can't be relied upon in this case.
Posted Jun 19, 2013 1:49 UTC (Wed)
by NightMonkey (subscriber, #23051)
[Link]
There's even GUIs:
Cheers!
Posted Jun 19, 2013 5:10 UTC (Wed)
by madscientist (subscriber, #16861)
[Link]
Posted Jun 19, 2013 7:10 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (8 responses)
Posted Jun 19, 2013 14:29 UTC (Wed)
by dgm (subscriber, #49227)
[Link]
Posted Jun 20, 2013 2:15 UTC (Thu)
by Fowl (subscriber, #65667)
[Link] (4 responses)
Apparently they contribute to libgit2 also, so if git on Windows wasn't working right once, I'd imagine it does now.
Posted Jun 20, 2013 11:41 UTC (Thu)
by imz (guest, #74088)
[Link] (3 responses)
Perhaps, a client using libgit2 could be expected to be more stable on Windows (compared to msysgit, if msysgit is not using libgit2).
I simply chose the most basic, non-custom client inthe hope that it is the one that can be believed to be the most stable one, the one tested a lot.
Posted Jun 20, 2013 19:56 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Jun 20, 2013 20:06 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Posted Jun 20, 2013 20:13 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Jun 20, 2013 11:37 UTC (Thu)
by imz (guest, #74088)
[Link] (1 responses)
Posted Jun 20, 2013 19:53 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Jun 28, 2013 18:30 UTC (Fri)
by moltonel (subscriber, #45207)
[Link] (2 responses)
If you have a small fix that needs to go into all your suported branches (possibly in a slightly different form), svn lets you do a clear single commit for all branches. With git you need one commit per branch (git cherry-pick will help), losing the connection.
Working in multiple branches at once :
If you need to work on multiple branches at the same time and like to use a single editor for all your files, git will get in your way by swaping the files on the filesystem and confusing the editor. Git prides itself on easy branching and merging, but it assumes that you only work one branch at a time (and close all your work when you switch branches). My workaround is to have one git clone per branch I'm working on.
Simplicity :
Even for a technical user that isn't SCM-averse (aka "me"), it is much easyer to shoot oneself in the foot with git. Oh yes, you can fix pretty much any mistake after the fact, but it may require a lot of skill to do so. It's often simpler to restart the procedure from a backup that you made just before performing $TRICKY_OPERATION than it is to restore the repository to a sane state.
Git is a great tool, but it isn't the flawless unmatched-in-every-field tool that many of its fans would have you believe.
Posted Jun 28, 2013 22:29 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
> If you have a small fix that needs to go into all your suported branches (possibly in a slightly different form), svn lets you do a clear single commit for all branches. With git you need one commit per branch (git cherry-pick will help), losing the connection.
Most projects should be able to branch off of the common merge base of all affected branches, make the patch, then merge where necessary. With single-commits-for-all-branches, what do you do if one branch needs it reverted at some point? Does "svn revert" work intelligently from a subdirectory? I suppose you could revert, commit the branch, reset the rest of the tree.
> If you need to work on multiple branches at the same time and like to use a single editor for all your files, git will get in your way by swaping the files on the filesystem and confusing the editor.
I thought there was some option for this? I found this[1], but it doesn't seem like a popular thing to do, so maybe there isn't. That said, I haven't had much of an issue with this behavior.
> Even for a technical user that isn't SCM-averse (aka "me"), it is much easyer to shoot oneself in the foot with git. Oh yes, you can fix pretty much any mistake after the fact, but it may require a lot of skill to do so. It's often simpler to restart the procedure from a backup that you made just before performing $TRICKY_OPERATION than it is to restore the repository to a sane state.
The reflog has indeed saved me multiple times (usually when splitting repositories into two separate ones with history or very hairy rebases). I wish more people were aware of it. My attempt at undoing a commit in SVN once involved quite a bit more work (dumping the server db, wiping a commit, restore the database[2]) than it has ever been in git (delete server clone directory, filter-branch/rebase/commit --amend/whatever, push).
[1]http://www.redhotchilipython.com/en_posts/2013-02-01-clon...
Posted Jun 30, 2013 2:13 UTC (Sun)
by foom (subscriber, #14868)
[Link]
It's not a core part of git "yet" (going on 5 years...), because it lets you shoot yourself in the foot even easier than is usual for git. E.g. if you checkout the *same* branch on two working copies sharing the same repo, you will be very sad, without any warning. Or, it lets you delete a branch which is checked out by a different working dir. Either way you'll end up with the other working dir's HEAD ref being changed out from under it, without the index being updated accordingly, getting you into a very confusing state of diffs.
But so long as you're careful not to do those things, then it's much nicer than having many separate local repos you need to push changesets between. I wish they'd get proper support in there at some point...
Posted Jun 18, 2013 16:06 UTC (Tue)
by smokeing (guest, #53685)
[Link] (2 responses)
Suppose you are midway working on a fix, and suppose you spot something else needing a fix which is totally unrelated to the primary task in your head, quietly begging for attention. What do you do? Leave a bookmark perhaps so you could come back once done with the primary task? That's where per-line granularity gitk gives you comes really handy. I just go ahead and fix everything, and then in gitk, I choose "Stage lines for commit", collecting in this way items for primary, and then secondary and any other, individual commits.
I wonder if a trick like this is possible in SVN?
Posted Jun 18, 2013 20:34 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Jun 19, 2013 8:19 UTC (Wed)
by dam (guest, #48438)
[Link]
Posted Jun 18, 2013 19:50 UTC (Tue)
by markhb (guest, #1003)
[Link]
Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
mercurial?
mercurial?
mercurial?
mercurial?
mercurial?
If you use git-svn then you make life of all your coworkers miserable: svn attributes are ignored, renames/merges of files are often messed up, etc. And if your answer is "oh, that's not a problem, everyone else should just switch to git-svn too", then the question becomes: why bother with svn at all?
If you want to use git-svn to grok some repo, then it's OK, but to contribute please use native svn client...
mercurial?
mercurial?
mercurial?
Recall how I'm using SVN: as a repository for non-technical people to check in documents and have them in centralized version control.
We're not using any of the advanced features of SVN
none of my coworkers even notices that I use git svn instead of svn directly.
mercurial?
mercurial?
mercurial?
In practice I've never seen anyone using git-svn getting noticed.
Yes I remember myself temporarily switching to the native SVN client to operate on SVN properties.
mercurial?
mercurial?
mercurial?
- an idiot not having a single look at the commits he pushes, plus
- a lawyer forcing him to add a copyright header longer than the rest of the file.
Subversion 1.8.0 released
2. You can be "technical" and allergic to version control in general. So go figure with git.
Subversion 1.8.0 released
Point 2. is wrong and should not happen but what you can you do about it? Not much except use something simpler than git, at least superficially.
Subversion 1.8.0 released
I find that an interesting observation because the second best thing I like about git is that the messes I make are so easy to clean up. No matter what I've done, it's usually just a matter of resetting a branch or two. With both bzr and svn I regularly got into situations where I didn't like what I had done to my repository but I had no idea how to go back. But then I've never used hg. Possibly it's even better :)
Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
"git checkout" is a particularly easy to way lose data.
While true, it will fail of git can't reapply your local changes.Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
what version control system won't overwrite files if you do a checkout?
I'm picking on git because git checkout file and git checkout branch are too similar. It's too easy to do the wrong thing.
$ emacs build.txt
$ git checkout build
$ git add build.txt
$ git commit -m 'updated build'
But this loses your edits:
$ emacs build.txt
$ git checkout build.txt
$ git add build.txt
$ git commit -m 'updated build'
I've had that second one happen to me when I thought tab-completion would fill in branch names, but it completed filenames instead. It's not a big deal, I'm just pointing it out as an example of how git can lose data other than "reset --hard" and scattered "-f". I still greatly prefer git to anything else.
Subversion 1.8.0 released
Subversion 1.8.0 released
Speaking of not conceding defeat, I have been known to grep through /dev/sda to find lost files :) It can work if they're short enough to fit in a few blocks.
Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
> Branch of repository to add as submodule. The name of the branch is recorded as submodule.<path>.branch in .gitmodules for update --remote.
> This option is only valid for the update command. Instead of using the superproject’s recorded SHA-1 to update the submodule, use the status of the submodule’s remote tracking branch. The remote used is branch’s remote (branch.<name>.remote), defaulting to origin. The remote branch used defaults to master, but the branch name may be overridden by setting the submodule.<name>.branch option in either .gitmodules or .git/config (with .git/config taking precedence).
Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
Wol
Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
argument to use something else instead of switching to Git: unpredictably unstable on Windows
argument to use something else instead of switching to Git: unpredictably unstable on Windows
http://cygwin.com/packages/git-gui/
http://cygwin.com/packages/gitk/
argument to use something else instead of switching to Git: unpredictably unstable on Windows
argument to use something else instead of switching to Git: unpredictably unstable on Windows
argument to use something else instead of switching to Git: unpredictably unstable on Windows
Microsoft actually support Git in Visual Studio (and their github equiv) now.
argument to use something else instead of switching to Git: unpredictably unstable on Windows
argument to use something else instead of switching to Git: unpredictably unstable on Windows
argument to use something else instead of switching to Git: unpredictably unstable on Windows
argument to use something else instead of switching to Git: unpredictably unstable on Windows
argument to use something else instead of switching to Git: unpredictably unstable on Windows
argument to use something else instead of switching to Git: unpredictably unstable on Windows
argument to use something else instead of switching to Git: unpredictably unstable on Windows
Subversion 1.8.0 released
Subversion 1.8.0 released
[2]Or something like this; it wasn't pretty.
Subversion 1.8.0 released
Subversion 1.8.0 released
Subversion 1.8.0 released
Partial commits for Subversion
Subversion 1.8.0 released