|
More power to you. Everybody should be blessed with that sort of experience.
Maybe what we did deviated from what was made available through the GUI, but we were strongly encouraged (by those who were familiar with the system) to "just do everything from the command line".
|
|
|
|
|
That is not unusual. There are a lot of people whose experience came up through non-Windows OSs that had nothing but a command line in most cases. They tend to want to force that 1990s way of interface on others now.
My point is that using Git in Visual Studio has been around with a GUI interface for years. If the less informed (like those telling you to use command line) choose not to use it, that is their problem, and it sounds like they made it your problem with which to deal. Sorry they hold you back like that.
|
|
|
|
|
Maybe I haven't made it sufficiently clear in the thread.
At the time, the company I worked for was on contract with Microsoft. You know, makers of VS and TFS. Those Microsoft people we contracted with were using Git, not TFS, and there was a very strong push, coming from them, to do everything at a command prompt.
These are not folks who don't know Microsoft products, or how to use VS or TFS.
Maybe I shouldn't be saying this publicly, but I'm not naming who I work for, nor the team at Microsoft we were working with. But internally, there's more and more support for Git - at TFS's expense.
|
|
|
|
|
You were clear. Microsoft, especially under the current CEO, suffers from a lot of command line, Linux-oriented developers and program managers who know little or nothing about MS’s past with GUI tools.
Even with visual tools that do all that is necessary, those oriented towards command line tools will still pretend a command line is needed.
I am not surprised you had folks at MS tell you that. I agree that they were sincere in their advice, just sincerely wrong.
That same mentality is why the software engineers (Alan Cooper’s team) back in the 1990s created a very useful GUI builder for Visual Basic (later ported to Visual Studio). But when extending Visual Studio to mobile apps (Xamarin Forms/MAUI) and web (Blazor), MS software engineers of the caliber they had in the 1990s and 2000s were long gone, and the command line oriented software engineers and program managers were not advanced enough to know how to build GUI builders for mobile and web, or to understand the significant value in them.
MS development tools suffer from not having visual designers, limited to the archaic “hot reload”.
The advice given to you about command line use of Git fits right in with a much wider engineering deficit at MS.
|
|
|
|
|
MSBassSinger wrote: back in the 1990s created a very useful GUI builder for Visual Basic
Having worked on a system that specifically was intended to build UIs long ago and having worked on a CMS (Content Management System) for the past 5 years that is used to build very large company sites I believe I have a bit of knowledge on such attempts...
And that is that UI presentations are never sufficient enough to do everything that knowledgeable individuals want to do.
|
|
|
|
|
And yet the WinForms GUI builder was so successful that other companies (like PowerBuilder) tried to copy it. It has successfully made Windows apps, including complex ones, to this day.
It isn’t that it can’t be done - it has already. It is that it has not been tried with a team capable of the same level of quality and excellence as Alan Cooper and his team had.
|
|
|
|
|
FYI
Power Builder predates even Visual Basic (codename Thunder) which means it almost predates the public internet.
I worked on a PowerBuilder 2.0 project talking to a DB running on OS/2!
It had form inheritance/templating at that version. Circa 1991.
|
|
|
|
|
PowerBuilder did not have a GUI builder anything like VB. Only after VB was out, did PowerBuilder create something similar. In fact, when I worked for the State of Florida, we were deciding on what tools to use for Windows application development for our agency. In the PowerBuilder presentation, the presenter stressed several times how PowerBuilder was like VB for building Windows forms. We looked at both equally, but VB was more advanced in terms of language and the GUI builder.
That was a long time ago.
The point today is the lack of a GUI builder for VS2022 that has the productivity for XAML and HTML/CSS that it has for WinForms.
|
|
|
|
|
Git sucks. TFS is awesome.
|
|
|
|
|
Strongly agree.
/ravi
|
|
|
|
|
Git is awesome. I know for a fact the only peeps that hate it are the peeps that don't know it. Name one thing TFS does better... I'm waiting.
Jeremy Falcon
|
|
|
|
|
I fully agree.
Based purely on my experience, I'll readily admit I'm not a fan of Git, but fully acknowledge that this is entirely because I don't know it well enough. I have zero doubt, at this stage, Git is the superior product.
I worked with a guy who loved it, and his enthusiasm for it was contagious. Who gets excited about TFS??
|
|
|
|
|
dandy72 wrote: acknowledge that this is entirely because I don't know it well enough My peeve is when people are full of fluff. If you like TFS just because you like it and that's the only reason why... you do you. It's when peeps start lying about another product they know little about as the justification, that's just no bueno.
dandy72 wrote: Who gets excited about TFS??
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: It's when peeps start lying about another product they know little about as the justification, that's just no bueno.
This. So much this.
In the case of Git vs TFS, like I said, I stick with TFS because it's all I'm comfortable with (right now) and I haven't had any real bad experiences with it. I managed to get myself in trouble with Git in the past (my own ignorance / my own fault), and fortunately I had people who helped me out, but I still have zero problem saying Git is the way to go. I just wish I had the time and motivation to learn it, and learn it well, from a good, up to date, and reliable source.
|
|
|
|
|
dandy72 wrote: I managed to get myself in trouble with Git in the past I'll admit, Git does have a higher learning curve. That's both good and bad ya know. There are things I can pull off with Git that would be impossible in other SCMs - I think. I know Git the best these days. What I do know for sure is that I can do just about anything one can imagine, but that comes at a cost of a learning curve.
Anywho, if you don't have a pressing need for it and you do have something that works, that's a totally acceptable stance. I say that all the time about tech. Time is finite. There's other things life... like going outside... that are important too.
dandy72 wrote: I just wish I had the time and motivation to learn it, and learn it well, from a good, up to date, and reliable source. Yeah, unfortunately, the best reliable source is other developers actively using it IMO. And even that's not a perfect scenario, but that's how I learned it. Git books never really did it for me.
Jeremy Falcon
|
|
|
|
|
dandy72 wrote: Who gets excited about TFS??
I don't get excited about any tool. Just as I don't get excited when I decide whether to use a hammer, saw or screw driver.
I do know that git, and this is by design, only does versioning(labeling) at the repo level. That is entirely appropriate for a tool that was designed for open source libraries.
But in a company enterprise system the ability to version (label) within a sub-code tree without managing subsystems as independent deliverables is something that can be very useful for large complex systems.
This is appropriate for mid-size companies where they have gotten big enough that there is now more than one team but not many.
When a company gets big enough of course they will start need to actively managing multiple deliverables including libraries. (It can be interesting to read what google uses for source control and git is not it.)
|
|
|
|
|
jschell wrote: I don't get excited about any tool. Just as I don't get excited when I decide whether to use a hammer, saw or screw driver.
Hypothetical situation: I suppose if you repeatedly have really bad, frustrating experiences with one tool, and have to put up with it for long periods of time (because there's just nothing better out there), then you find out about some other tool, give it a try, and it works a lot better - and you never go through a bad experience ever again - that'd be reason enough to get excited about something.
I'm not saying this is what happened with my coworker, but I had to smile at his enthusiasm using a software program. You don't see that often. Bless him for that, I say.
|
|
|
|
|
dandy72 wrote: frustrating experiences with one tool,
Yes. Except of course it doesn't even need to be plural.
|
|
|
|
|
Labels. Git doesn't have them at all and they are critical. And an API / .net integration. And integrated ticketing.
Edit: Here's what the Users' Manual for CMS has to say about Classes (which are very like Labels in TFS.)
5.1.2 Classes
A class is a set of specific generations of elements that can be manipulated as
a unit. A class can hold only one generation of any element.
You use classes to represent the state of development of a system or set of
elements at a particular time or stage. You can think of a class as a picture
taken of a library at a particular time. For example, you might create a class
named FIRST_DRAFT that contains only those generations of elements that
were used in producing the first draft of a manual.
Typically, you create a class to contain generations of all the components of a
software system for a release version of a product. You can establish classes
for different stages or milestones. For example, you could establish one class
for implementation, a second for testing, and a third for generations that
have completed the first two stages. As each module progresses through each
stage, you assign each generation to an appropriate class; thus, you can easily
determine your progress by displaying the contents of the different classes, and
you can later reconstruct any stage of development.
Once you insert an element generation into a class, further changes made to
the element are not reflected in the contents of that class.
HP DECset for OpenVMS
Guide to the Code Management System
Order Number: AA–KL03H–TE
July 2005
In particular: "or set of elements" -- the developer has full control over which generations of which elements are included in the class.
Note that VSS does not have such a feature, but it was included in TFS.
CREATE CLASS class-name[,...] ‘‘remark’’
Command Qualifiers Defaults
/[NO]LOG /LOG
/OCCLUDE[=option,...] /OCCLUDE=ALL
Creates one or more classes. After creating a class, you can place any related
set of element generations in that class by using the INSERT GENERATION
command. The CREATE CLASS command does not automatically place any
generations in the created class. For more information on classes, see the
HP DECset for OpenVMS Guide to the Code Management System.
HP DECset for OpenVMS
Code Management System
Reference Manual
Order Number: AA–QJEVC–TK
July 2005
The phrase, "any related set of element generations", may give the impression that there already has to be a relationship between the elements in the repository, but that is not the case. Adding generations of elements to a class defines a relationship between them.
modified 2-Nov-23 13:57pm.
|
|
|
|
|
PIEBALDconsult wrote: Labels. Git doesn't have them at all and they are critical. They're called tags in git. Seriously man, we're supposed to be better than this.
PIEBALDconsult wrote: And integrated ticketing. I'm guessing you don't use any non-MS product? I'm sure there are tons of other products that do but Jira, as one example, has integrated with Git for years now. I mean years.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: They're called tags in git.
No, those are a totally different thing. And I see no purpose for them.
From what I see (RTFM), a Tag in Git (or Subversion) includes a version of all of the items in a repository.
That's not what a Label in TFS (or a Class in CMS) is. With a Label or Class, you include only the items you are interested in -- which could be all of them, but usually not.
Git should add this feature, it shouldn't difficult, and it will make things so much easier.
modified 2-Nov-23 12:28pm.
|
|
|
|
|
How so? Isn't the purpose of a label to find a specific commit?
To quote Microsoft:
Team Foundation Version Control (TFVC) labels provide a way for you to take a snapshot of your files. Later, you can refer back to that snapshot. By using your label, you can view, build, or even roll back a large set of files to the state they were in when you applied the label. I realize you can name labels in TFS. You can also name tags in Git. So, how is it not the same thing?
Jeremy Falcon
|
|
|
|
|
As I said, a Label typically contains only a small subset of the items in the repository.
Edit: That quote from MS is just a very brief overview of what Labels can be used for. It basically says nothing about what Labels are and the broad range of what they can be used for.
If a Git user finds himself using TFS and wants to know how to make the equivalent of a Tag, the answer is a Label, but that doesn't mean that Labels and Tags are the same thing, they are not. They are not equivalent; Labels are greater than Tags.
Find the actual documentation for Labels and read it.
modified 6-Nov-23 13:43pm.
|
|
|
|
|
Ok, so if it's backwards... then as I said Git already does that. You still didn't define what constitutes a subset btw. So, let's just assume it's a diff of files that changed between commits. Git does this. Saying it doesn't isn't correct.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: it's a diff of files that changed between commits
No. That is not what a Label/Class is. That may be a typical use for a Label, but I can put any version of any item in the repository in a Label any time I want. An item/element doesn't need to have changed to be put in a Label/Class.
|
|
|
|