Hit with the stupid branch...
-
@dhromed said:
@OzPeter said:
MS has also announced Git support in TFS
Que? That's weird.
Isn't that like gecko supporting webkit, and Photoshop supporting GIMP?
Maybe you mean Git support in VS?
I am blissfully unaware, so that's why I ask these questions.
To be honest, there is Photoshop support in GIMP, and Mozilla threatened to support Webkit until the W3C flipped out and told vendors to drop CSS and DOM prefixes.
-
@MiffTheFox said:
To be honest, there is Photoshop support in GIMP,
"To be honest"? Why would you lie about that? Now I can't ever trust you again!
-
@dhromed said:
@OzPeter said:
MS has also announced Git support in TFS
Maybe you mean Git support in VS?
Looks like both, apparently.
@Hansleman said:
For me personally, the term "TFS" has historically meant "big scary corporate centralized source control" while Git has meant "small scrappy lightweight distributed source control." TFS meant connected (ZOMG, I can't code on a plane!) and Git meant occasionally connected (ZOMG, I don't know what rebase means!).However, I learned that Team Foundation Server (TFS) isn't just source control, it's a whole bug tracking, change management, application lifecycle management (ALM) suite. Source control is one pluggable piece.
On the other hand, Git isn't just source control either. Git has become effectively FTP for code. I use Git to deploy most of my sites as mentioned in this blog post where have a site automatically deploy as I publish to GitHub. Git is also used as an interchange tool to move code between different SCMs, and it's supported everywhere, although Git tooling support on Windows has historically lagged behind.
Things start getting interesting if one could have Git as their source control with Team Foundation on the backend for ALM tools. Now Visual Studio 2012 supports both centralized version control and distributed version control in a cleanly integrated way.
-
@blakeyrat said:
@MiffTheFox said:
To be honest, there is Photoshop support in GIMP,
"To be honest"? Why would you lie about that? Now I can't ever trust you again!
-
@dhromed said:
I mean something like Microsoft embraces git with new TFS support, Visual Studio integration@OzPeter said:
MS has also announced Git support in TFS
Que? That's weird.
Maybe you mean Git support in VS?
Git in the VS front end and Git in the TFS backend
-
@boomzilla said:
With a DVCS, when you check in your changes, they're still creating a diff from r100. So you end up with:
This explanation misses a key difference. With a DVCS the version numbers aren't sequence numbers. How could they be? There's no way to synchronize the issuance of members of the sequence. Instead, the identifiers are hashes (typically cryptographic hashes of the manifests that identify the exact versions of the files that make up the version) so that everyone can independently create numbers without danger of clashing. Like this, if there are two clashing commits that subsequently get both pushed to a repository, it's still possible to figure out what happened and fix it.r100 - r101 - r103 \ r102 /Now, you have to merge r101 and r102 just like you would with any other branch. But you have a clear record of both of those changes. Most of the time, this isn't a problem with svn. But when it is, it can be very difficult to deal with, especially when there are significant changes. And you risk getting your stuff wiped out, or at least severely messed up when svn forces you to merge r101 into your working copy before you were able to record r102, because your r102 changes are transient. So if you mess up with the merge and reconciliation, you can't simply roll back to a previous change (unless you backed up / copied your source tree before updating from the repository).
Fixing it, doing the merge, can be somewhat non-trivial if the clashes are bad. But more often than not, it's possible for automatic merge application to sort it out: there are changes to the same file, but not to the same region of the file. Who is actually on the main branch? Well, that actually depends on your point of view; it's possible to get into quite a pickle if everyone tries to merge in favor of everyone else. (Yes, tools to visualize the branch structure as currently understood by a particular repository instance are a very important part of a DVCS ecosystem.)
The big difference between the various DVCSes that are out there — git, mercurial, fossil, etc. — is not in the fundamental model of what is happening, but rather in the workflow that the tools support most smoothly. For example, fossil is designed much more for smaller teams than git is, so it encourages synchronizing more often and requires you to really insist (via an extra option; GUI types can think of it as being almost an "are you sure" dialog, except for the command line) if the commit isn't off a branch tip. That wouldn't be comfortable for a project as big as the Linux kernel! Lots of projects are much smaller than that though...
-
@dkf said:
This explanation misses a key difference. With a DVCS the version numbers aren't sequence numbers.
Way to miss the point and be wrong at the same time. Mercurial assigns sequential numbers to changesets in a repository, though they obviously only have meaning within that particular repository. This can make life a lot easier for the user.
@dkf said:
The big difference between the various DVCSes that are out there — git, mercurial, fossil, etc. — is not in the fundamental model of what is happening, but rather in the workflow that the tools support most smoothly.
This is definitely true, and as I've said many times, there is nothing inherent in centralized VCS that requires merge-commit, that's what at least some of them do. I would be a lot less unhappy with svn if it followed commit-merge.
-
@boomzilla said:
I would be a lot less unhappy with svn if it followed commit-merge.
But... but... that would mean a repo full of...
BRANCHES!
-
@flabdablet said:
@boomzilla said:
I would be a lot less unhappy with svn if it followed commit-merge.
But... but... that would mean a repo full of...
BRANCHES!Fuck, you're right. And then, the next thing you know, there would be tags, too.
to be honest - Wiktionary, the free dictionary
