On Friday, 25 September 2015 at 14:29:33 UTC, Kagamin wrote:
On Friday, 25 September 2015 at 03:00:12 UTC, Jonathan M Davis
wrote:
I, for one, was very excited when I found out that you could
actually run VS builds from the command line rather than
having to open up VS. And at my last job, I redid our build
stuff so that we used cmake to generate the build stuff for
both Linux and Windows so that we didn't have two build
systems to maintain, and with that, the _only_ reason that I
ever had to open up VS was to debug on Windows. It was great.
Unfortunately, at my current job, we're entirely Windows, so
everything's a huge mess in VS rather than using cmake, and
most of the devs are totally Windows devs, so they'd probably
freak out at the idea that the .vcproj files are generated,
and you don't edit any settings inside of VS. So, there's no
way that I'm going to get the beauty of cmake again here. I'm
forced to open up VS more - and we're using the muck that is
TFS, which pretty much requires opening up VS to manage source
control (though the TFS power tools help).
TFS has a CLI client. Why would you automate builds if you
can't automate getting fresh sources from source control?
I don't know what you mean by automating in this context. I'm not
automating anything. This is all stuff that I'm doing as I
develop, not stuff dealing with nightly builds or anything like
that. Do you mean build from the command line? I did that at my
previous job where we were using cmake and had made the directory
structure very neat, and all of the VS stuff was separate from
the actual code, since we didn't build in the source directories,
but at my current job, everything was set up with VS by folks who
use VS for everything, and the directory structure is a complete
mess, making doing stuff from the command line a lot messier than
it should be. I have done some TFS stuff from the command line
but not a lot, since I'm stuck having the GUI open anyway, and I
tend to touch TFS with kid gloves, because it seems to behave
badly in general, and I have to be really careful that I don't do
something like commit code from multiple branches at the same
time or merge stuff badly.
What I really want to do is use git-tfs (and maybe even use that
in an attempt to convince folks to switch to git from TFS), but
for some reason, it doesn't work correctly with our repos - it
doesn't pull in a lot of the files, making it unusable. The sad
thing is that when they chose TFS a while back (before I was
working there), the lead dev was pushing for Mercurial, but the
other folks didn't listen, and he lost (even though he had
Mercurial up and running very quickly, and they took over a week
to sort out TFS). So, we could have had decent source control,
but we're stuck with TFS instead - probably because most of the
devs involved are too Windows-centric. And given how messy the
TFS branching stuff is (e.g. it doesn't retain history when
merging), I bet that using git or mercurial would save our build
guy a ton of time, but he just wants to use TFS and thinks that
it's great (probably because it's what he's used to, and it's
from MS).
- Jonathan M Davis
