I think this is a *little* overstated, but not by too much. I will state
that I've been using Mercurial for my personal repos over a TFS master copy
for almost a year at this point. Is it seamless? No, but it does work and
lets me easily do the DVCS thing for myself (and coworkers who are similarly
enlightened) and still keep the corporate overlords happy.

 

As far as the "check it in if read-only changes thing", that's not quite
what happens. When you do a check in, yes, the file shows up in the checkin
dialog, but the server will detect there's no actual change and actually
remove the file from the changeset (and reset the read-only bit, which is a
PITA).

 

Branching always seemed to be just about the same as SVN to me, but I freely
admit I didn't use branches much in SVN. I'd love to hear why you think it's
so much worse than SVN. Blows chunks compared to Git or Mercurial?
Absolutely.

 

Yeah, completely agreed that server-side client state and workspaces are a
huge PITA.

 

-Chris

 

From: [email protected] [mailto:[email protected]]
On Behalf Of Jeff Schumacher
Sent: Wednesday, January 26, 2011 12:27 PM
To: [email protected]
Subject: Re: My company just decided to implement Team Foundation Server,
should I be concerned?

 

Adding to what Scott said (all of which I've experience):

1) TFS maintains it's OWN list of what is on your file system.  So if you
have the latest version of c:\project\foo project from TFS, and then you
delete foo using windows explorer, then tell TFS to get latest, it will NOT
recognize that you have actually deleted the files off your filesystem and
will report 'You already have the latest version'.  At this point you have
to force TFS to give you a specific version and tell it to overwrite
everything on your disk

2) Using something like git or Mecurial with TFS as the central source is
almost impossible.  

3) TFS maintains state on files by inspecting their "read only" status. If
you make a file writable, but do not actually change anything, TFS will
think it has been changed and want you to check it in

4) It's just about impossible to have multiple copies of a repository on
your computer. TFS expects that you will only ever need one copy of the
code. It's idea of "workspaces" is nothing but friction

5) Branching is HARD in TFS. You cannot even compare it to SVN, let alone
git or Mercurial.

6) It costs money. Subversion: free. git: free. mercurial: free.  There's a
small upfront learning curve cost, but they quickly pays themselvs off with
so much less friction.

 

I could go on.  As someone who also "upgraded" (sideways graded is more like
it) a company from VSS to TFS, I would say "FIGHT THE POWER!" I would never,
ever do this again. Everyone I know that has ever used it, complains about
TFS. There's a very good reason that we call TFS things like "Team Friction
Server" or "Team Frustration Server" or "THAT F-ING SERVER!" 

On Wed, Jan 26, 2011 at 9:44 AM, Scott Koon <[email protected]> wrote:

 

In my experience the main pain points surrounding TFS have been:

1) Weird file locking, sometimes TFS will tell me that I have the file
locked when I don't.

2) Branching seems to be a heavyweight operation and that makes people
hesitant to branch.

3) GUI is slow and the CLI tools still pop up GUI windows(?!) 

4) The workflow is integrated. This might sound like a good thing, but in
reality it means that people try to incorporate the default workflow into
their business process and it never quite meets everyones needs. You can try
to find different scrum/agile templates out there but they are kind of a
pain to install and modify and again, don't quite meet your needs

5) People don't use shelves frequently enough.

 

-- 
You received this message because you are subscribed to the Google Groups
"Seattle area Alt.Net" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected]
<mailto:altnetseattle%[email protected]> .
For more options, visit this group at
http://groups.google.com/group/altnetseattle?hl=en.

 

-- 
You received this message because you are subscribed to the Google Groups
"Seattle area Alt.Net" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/altnetseattle?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Seattle area Alt.Net" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/altnetseattle?hl=en.

Reply via email to