TFS Upgrade!
-
Don't get me wrong, after being re-exposed to TFS recently I was greatly disappointed in its lack of forward progress. And Microsoft seems to have just utterly given up on even trying to make it usable.
But it's not a bad tool necessarily. And still more usable than 90% of alternatives.
-
Managing patch files for a single commit you want to do isn't too bad... but once you have two changes you want to make (where both have a file in common) while you don't have repo access, it suddenly becomes a PITA. Or if you have copies/renames. The CLI Subversion client provides zero tools for helping in this situation, and while I don't know for sure I doubt Tortoise helps either.
I'm pretty sure Tortoise's Patch commands can handle renames and copies. And if not, it has an easy way when adding a file to mark it as a copy of a still existing file or a rename of a "missing" file.
Changes that don't share files in common work well enough for me with changelists (I think they are available on the CLI client too). When changes share files, the best way Tortoise can handle it: When editing a diff in the diff editor there is an option to "Revert changes after commit". It tended to be buggy in corner cases (like when you did not actually commit immediately, or when the commit failed due to working copy out of date), but recently worked well enough for me in the 5 or so times I needed it (when interrupted for a quick bugfix during development of a new feature and did not realize that I made changes to the file before). Still miles away from
git add -p(although that command's interactive help might be confused of that of a dating site), but better than nothing.
-
-
Commits to a central server are one of the most stupid ideas in software development.
Here in the corporate world it's necessary that commits eventually find their way to the central server as that is the source of authority on software versions for the corporation.
central/remote branches are the stupidest idea
What do you mean by this?
The main problem people have with DVCS is that with CVCS (CVS, TFS, SVN) there's a person responsible for the repository that makes all the decisions and are able to fix the sort of fuckups that morons make. With DVCS, fuckups are yours and you have to fix them by yourself or you won't be allowed to push your crap so others can consume it.
Your comments don't match with my experience of reality. I am the git guy here. I get to fix the central repository and the cloned local repository for the one remaining user who can't (or won't) learn. I get to give advice on how to best use branches, when to merge, etc. I'm the guy who writes the hook scripts. I'm the nazi who wrote the script that rejects your commit because it doesn't have a Jira issue key or THE COMMIT MESSAGE IS IN ALL CAPS (same not-learning-guy keeps caps lock on because SQL because of course SQL is always all-caps and after thirty years of using computers still uses two-finger hunt and peck so doesn't see what he's typing).
Corporate software development has a central repository, even with DVCS.
-
each repo locally has the sequential number [...] damn useful for doing stuff with your repo
Meh. It's not that hard to copypasta the first 6 or so characters of a SHA hash, or even the whole thing.
-
Meh. It's not that hard to copypasta the first 6 or so characters of a SHA hash, or even the whole thing.
That's true, but it's still easier to be dealing with numbers.
-
I am the git ... Nazi
I worked at a place with a source control Nazi once. IIRC we used some weird-ass wrapper around RCS.
He was totally anal about "don't modify or reformat a single line of code other than the ones you're working on for your issue, because it makes diffing hard." He'd reject commits that did that kind of thing.
-
My personal opinion is that the reason svn branches are more obnoxious to use is [...] (2) they go into a global namespace, so if you want to create a branch for something you're working on you have to worry about name conflicts with others or policies about what branches you can have or just general pollution of having to look through potentially a lot more stuff to find what you're looking for.
WTF? You can put your branch in any subdirectory you want. That's the whole point of directories: hierarchical namespace management. Just use them.
-
Only in TheDailyWTF you would found someone defending TFS.
I like it. It Just Works for the basic stuff, and integrates very nicely with VS - right click, commit, that's it, no hunting and pecking to see if all the files in the solution are actually in the commit.
I suppose Git/Hg is easier if you branch out a lot, but with a streamlined project, it's good enough.
-
WTF? You can put your branch in any subdirectory you want. That's the whole point of directories: hierarchical namespace management. Just use them.
Not an option if half of your team uses git-svn.SVN, if used right, is a good tool that does its job just fine. Git, if used right, is even better, even though little bit harder to wrap head around. git-svn is the way to use both those tools wrong at once.
-
I suppose Git/Hg is easier if you branch out, but with a newborn project, it's good enough.
FTFY.
-
The best thing about SVN is
svn-git.
Except that you shouldn't use it when you're still learning the ropes of git. Suddenly you get hit by SVN trouble and git-rebase-crazyness...
Plus git-svn branching is damn hard.Not an option if half of your team uses git-svn.
Ah, TRWTF.
As an aside: I always wonder how well SubGit's claims of dealing with this kind of madness holds up in reality. It's a commercial tool so they have the incentive to improve, but it does sound quite ambitious to integrate Subversion and Git in a two-way manner.
-
As an aside: I always wonder how well SubGit's claims of dealing with this kind of madness holds up in reality. It's a commercial tool so they have the incentive to improve, but it does sound quite ambitious to integrate Subversion and Git in a two-way manner.
The main problem we encounter with svn-git is that git doesn't track mergeinfo of subfolders. Makes svn merge almost unusable - and git merge too, if someone merges non-top-level directories via SVN. If SubGit does this part properly, then it's fine - but I really, really doubt it.Thankfully, soon we'll switch fully to Git. And to C++11.
Filed under: double blakeybait
