|
I know what a Tag is (in Subversion and Git). I have known what a Tag is for many years. I do not need to read your posts to know what a Tag is. You have told me nothing which I didn't already know.
You seem to have a problem understanding what a Label (in TFS) or Class (in CMS) is, even though I have tried to explain it several times now.
The closed mind is on your side, not mine. You are convinced that a Tag is the same thing, when it most definitely is not. Labels and Classes are much more flexible than Tags.
|
|
|
|
|
"It should be possible to explain the laws of physics to a barmaid." - Einstein
Just because you said you know what we're talking about, while not actually engaging in the chat, means you're just saying that. Go on, be that way. You don't need friends.
Jeremy Falcon
|
|
|
|
|
Then show me that Tags are as flexible as Labels. So far you have not, even though I have asked you to. To this point, all I have seen you doing is denying that Labels are more flexible than Tags -- even though they are.
I have tried to explain the flexibility of Label several times in this thread, but it seems to have fallen on deaf ears. Maybe the failing is on my side, so I'll try to explain it with an example...
Let's say I have a repository, and I check in v1 of files A, B, and C.
With Git (or Subversion) I can create a Tag which represents a snapshot of v1 of those three files.
Then I check in v2 of those files.
With Git (or Subversion) I can create a Tag which represents a snapshot of v2 of those three files.
Correct so far? Yes?
If I am using TFS (or CMS), I can create Labels (Classes) which do exactly that, but I can also create Labels (Classes) which:
Contain v1 of file A and v2 of file B and does not include file C.
Contain v2 of file A and v1 of file B and does not include file C.
Labels and Classes can also be modified after they have been created -- perhaps after v3 has been checked in.
My understanding is that Tags in Git and Subversion cannot do that. Am I wrong?
Whether or not you in particular have a need for this feature is irrelevant. CAN Tags (or some other feature I don't know about) in Git do that? I have seen no evidence in the documentation that it can. If so, where does the documentation explain how to do it?
IF Git actually does have a feature which provides the functionality of Labels (in TFS) or Classes (in CMS), then I need to know. But, to my knowledge, it is not Tags and so far you have not addressed that question.
|
|
|
|
|
I deleted my reply because I don't want to be a part of this conversation anymore. You can think what you want. I don't care. You're flying solo now.
Jeremy Falcon
|
|
|
|
|
 Jeremy Falcon wrote:
This is the first time you actually talked to me. The fact you get all uppety over your poor communication skills is pretty sad man. So now, I'm going to freaking repeat myself. If you choose to ignore me twice, that's on you. But you're wasting my time here and this point I'm going to bill you. This is childish and ridiculous. NOW, SINCE YOU ARE TALKING DOWN TO ME... (GO AHEAD AND DENY IT) I'LL USE BOLD TOO. PIEBALDconsult wrote: Labels and Classes can also be modified after they have been created -- perhaps after v3 has been checked in. I've addressed one way to do that, but I'll explain another. IF YOU DO NOT UNDERSTAND GIT THAT'S OK. JEEZE. But, if you need to do that, you can create a commit and tag it that 100% is cherry picked from different commits or DIFFERENT VERSIONS OF COMMITS. THIS IS 100% DOABLE SO NEXT TIME READ MY POST. PIEBALDconsult wrote: Labels and Classes can also be modified after they have been created -- perhaps after v3 has been checked in. THIS IS NOT A GOOD THING. GIT WORKS MORE LIKE THE BLOCK CHAIN. IF YOU WANT TO MODIFIY THAT THEN CREATE A NEW COMMIT WITH WHATEVER CHERRY PICKED FILES YOU WANT AND RECREATE THE TAG OFF THAT. PIEBALDconsult wrote: Am I wrong? YES! In two ways, the second being you don't actually read the posts you're arguing on. I don't care anymore if you deny that, any intelligent person knows the truth. Anything else you want to say? I've already lost all respect for you. Jeeze. This is the reason I loathe CP at times. What a waste of life.
Thank you for finally acknowledging that you understand that Tags in Git are not the same as Labels in TFS and Classes in CMS. Now please stop telling people that they are, because that's wrong. Labels and Classes are superior to Tags.
Perhaps you are saying that Tags in Git are better than Tags in Subversion. I hope that's true anyway.
Jeremy Falcon wrote: This is the first time you actually talked to me.
No, it isn't. I have replied to many of your responses, but you have not addressed my concerns until now.
Jeremy Falcon wrote: I've addressed one way to do that
No, you haven't. All I have seen you do until now is repeat what I already know from the documentation.
Jeremy Falcon wrote: tag it based on files that are 100% cherry picked from different commits
Show me the syntax to do that. I have seen no such command in the documentation.
Jeremy Falcon wrote: THIS IS NOT A GOOD THING.
It is a very good thing. Yet Classes in CMS (I'm unsure about Labels in TFS) can be locked to prevent changes.
In the team I was on which used CMS, there was a Class for the next build. We developers would add items to the class throughout the sprint, then when it came time for the build, the configuration management team would lock the Class and begin the build.
Freedom beats prohibition in every case.
Jeremy Falcon wrote: CREATE A NEW COMMIT
Why the frack would someone create a needless commit just to create a Tag? That's insane.
Jeremy Falcon wrote: WITH WHATEVER CHERRY PICKED FILES YOU WANT AND RECREATE THE TAG OFF THAT
That's insane. It is nowhere near as useful as Labels and Classes which can be created and managed months or years after a commit.
I ask again: Can you perform the exercise I described above with Git? I believe you just said that you cannot, which is what I have been saying all along but which you have been denying.
You don't have to like it, but I need it.
modified 8-Nov-23 10:03am.
|
|
|
|
|
PIEBALDconsult wrote: With a Label or Class, you include only the items you are interested in -- which could be all of them, but usually not.
If you define files you're only interested in as files that changed for a commit, my understanding is that is a changeset. Keep in mind I haven't used TFS in years, so my memory is rusty.
What non-Git peeps don't get is that Git doesn't need that feature. Git was designed from the ground up to be great a diffing, merging, etc. I've never seen another SCM do it better. If I need to figure out which files changed between commits, tags, or branches it's just one simple command away. So, Git can already do this.
Jeremy Falcon
|
|
|
|
|
I suspect you never used Labels in TFS either, many people don't.
Jeremy Falcon wrote: If you define files you're only interested in as files that changed for a commit,
Certainly, but...
A Changeset may contain items which are not to be deployed.
A Label can contain versions of items from multiple Changesets.
Jeremy Falcon wrote: Git doesn't need that feature
Yes, yes it does. And I suspect they can alter Tags so they do it.
Jeremy Falcon wrote: If I need to figure out which files changed between commits, tags, or branches it's just one simple command away. So, Git can already do this.
That's not what Labels are for, and TFS can do that as well of course.
|
|
|
|
|
PIEBALDconsult wrote: That's not what Labels are for, and TFS can do that as well of course.
Given this video (it's 2 minutes only), either this dude is wrong or labels are meant to tag a specific set of files, as well the MS link suggested...
TFS 2013 Tutorial : 24 - How to Apply Labels in Team Foundation Server 2013 using visual Studio - YouTube
You can modify tags in git and labels in TFS so I'm not sure why bringing this up is relevant.
If you need to stage files not marked for release that are in your repo for some reason, let's say internal documentation, that can be achieved with git 100%. However, that's a bad design to do that in the SCM itself. Anything exclusionary should be a part of the build process. So, to keep this on point... right now, I'm mentally considering a changeset like a commit in Git terms.
Given that, if for some reason you need a label of two different changesets that are completely unrelated (history-wise) to one another in a label, again Git doesn't work that way. Nor should it. That's just a bad design. If you need that, then merge or rebase into whatever branch you're working on in question and create a tag off that. You'll have exactly the same thing but with a consolidated history trail.
Git is more analogous to the blockchain in terms of a history trail. That's a good thing.
Also, if labels aren't used to tag a release, why are people saying it is?
Jeremy Falcon
|
|
|
|
|
OK, so now I've watched the video, and, as I expected, it seems to cover only that one simple use case which mimics Tags (though maybe it doesn't). But it says nothing about the full power of Labels. The presenter isn't wrong, but the video may leave viewers thinking that that's all Labels are good for.
As I have said several times in this discussion, Labels are much more flexible than Tags. Tags are stupid, I see no real world reason to use one. Git should add the same flexibility to Tags, then it will be usable.
I will also state that I would never create a Label the way the presenter demonstrates it. It can be very dangerous to do that in a high-velocity team environment.
In that regard, as I mentioned in my original response, I need an API with which I can implement a utility to standardize how Labels are created and maintained for my team. The TFS GUI in VS was not good enough for the job. Using TFS' .net API, I was able to write a utility which used the tickets and changesets to create the Labels we needed.
modified 6-Nov-23 13:49pm.
|
|
|
|
|
Btw, I have used labels in the past, but that was like well over a decade ago. Seems like forever and I totally accept my memory is fuzzy in that regards, so I could be going senile. 
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Name one thing TFS does better... I'm waiting.
Shelve sets that reside on the cloud vs. stashes that reside on a local machine.
Disclaimer: I'm not a Git expert and don't claim to be one.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: Disclaimer: I'm not a Git expert and don't claim to be one.
Thanks for being the first person to actually make a legit point though. You're right about that btw. So, can totally see how it would appear on the surface. It's a difference of philosophy though.
Git is all about branching. Way more than most SCMs. Stashes are meant to be about uncommitted changes. It's not always stuff you want to share. If there's a change set you want to keep on a remote server because you want to share the code or access it on another machine, just put your committed changes in a branch. You can have temporary branches all day long.
It's just a difference of philosophy, where branches are used to the extreme in Git, but it's doable. Git really does excel at merging, so branches are used a lot.
Jeremy Falcon
|
|
|
|
|
Perhaps I'm not using stashes the way they were intended to be used. Let me explain my scenario and maybe you could suggest a better approach.
I work on a large enterprise app that consists of a dozen web API apps. During development, the apps are deployed to my local IIS at the end of a successful build. Each app's web.config needs to be tweaked to reference the developer's machine and development port numbers, and databases that reside on the dev's SQL Server. So what I stash is essentially my set of machine specific web.config files. My daily work routine is as follows:- Stash web configs and have no local changes.
- Pull latest code.
- Unstash web configs.
- Build locally.
- Work on my tasks.
Before I create a pull request, I create a branch with my changes and create the PR from that branch. When the PR completes, I delete that branch.
Maybe there's a better way of doing steps 1 and 3?
/ravi
|
|
|
|
|
You're doing it exactly the way you should, including deleting temporary work branches. And, I can 100% see why you'd want to have local configs shared somewhere. The question is where? Should that be in the repo? From a security perspective some will say, never put connection info anywhere in a repo / where it's not needed, and I personally fall into that camp. Especially because git will never forget changes and booboos happen. But then, life happens too. 
So, given that, you got a couple options:
- You can still push a stash remotely, but it's a pain compared to other SCMs. But if you want ideas, scroll down until you see Scott Weldon's answer. You can totally work with detached heads and commits in git, as long as you remember the short SHA, where git puts stuff, etc. Of course, this is a pain to do. But if you're just looking to backup/share something every now and again, it may be worth it.
- If the structure of that file is the most important thing (so you can remember what settings you need), you can always create a template settings file that contains everything but the actual connection values and put that into the repo permanently. This is what I do, using something like dotenv (been the web world lately). But, there will be a template file that shows everything that needs to go in the actual config that gets committed while the real values are saved elsewhere. This way you can share the how but not the what.
I guess at the end of the day, the difference is, for connection info, I'll put that in Confluence or something if it needs to be shared. Both ideas of keeping it in the shared repo (all in one place) and keeping out out of the shared repo (security) have merit ya know.
Jeremy Falcon
|
|
|
|
|
Thanks for your reply.
Unfortunately it's not just connection strings but IIS port numbers. These are specific to the developer's machine. I've decided that the fastest way forward is to write an automated script that updates a dev's config files. Devs will use this script at the start of their workday. But IMHO this is a workaround for something (remote stashes) an SCM should provide out of the box. 
/ravi
modified 8-Nov-23 2:03am.
|
|
|
|
|
Ravi Bhavnani wrote: But IMHO this (remote stashes) is a workaround for something an SCM should provide out of the box.
Fair enough. Thanks for being the first person to say something legit though. There's another dude going on for days who clearly doesn't know what he's talking about it. So, your chat was totally refreshing.
Jeremy Falcon
|
|
|
|
|
Maximilien wrote: Maybe there's just something I don't get from the system.
It's not you.
|
|
|
|
|
Stick with git. It'll take you much further and make you more flexible.
Jeremy Falcon
|
|
|
|
|
I haven't run into any issues with using Git. I use Git via Visual Studio and Azure DevOps Repos, and to me, it is seamless. I get the idea of a local repo and a remote repo, with branching, that Git uses. I have used Bitbucket and Subversion, liked both, and found I like Git more, especially for team use.
|
|
|
|
|
Maximilien wrote: but going from git to TFVC feels like a step back.
Because it is a step back...
TFVC is a centralized version control system, like Subversion.
You basically went from Git, which is decentralized, back to a different flavor of Subversion.
Microsoft has been ditching TFVC in favor of Git for years now.
|
|
|
|
|
Exactly. I dunno about you, but a good dev does frequent (ok, not too frequent) commits. I don't miss slow commits at all.
A commit is a check-in for the non-git folk among us.
Jeremy Falcon
|
|
|
|
|
When I was managing a dev team of 6 on a pretty large codebase, we used TSVC and later Git. TSVC worked very well for us, and was relatively easy to manage. The obvious difference was centralised vs. decentralised/distributed. We didn't need that complexity. Torvaulds designed Git because he was managing many developers spread around the world in different time zones, and the distributed nature of Git matched that. You pick the tool suited to the job in hand.
Moving from any tool you are familiar and competent with to another is often going to feel awkward, if not a backward step, until you are experienced with the new one. Persevere and you will eventually find they both have their strengths and weaknesses.
With regard to "must use commandline" (or Gui) I find the professional elitism or evangelism that pervades so many software developers irksome and irritating, and use of the command line as some sort of implied superiority especially so. I use the command line myself when it's easier or has options I need that are not supported by the available Gui tools, and Gui tools when they are more convenient. The commanline is useful for automating processes with scripts, most other times it's easier to use a Gui. Just pick the approach that suits the circumstances.
|
|
|
|
|
|
"Use the right tool for the right job." Git is not the right tool for any job I've had, but TFS is.
I have never had a job in which a distributed version control system would make a positive difference.
I found TFS to be much more usable than Git -- TFS just worked. Git was a step back. Maybe the Visual Studio Git integration will some day be up to what we have with TFS.
For myself, my experience is more like:
CMS (OpenVMS) -> look at VSS, reject it -> look at Subversion, reject it, get forced to use it anyway -> rolled my own* -> Subversion again, but with Tortoise -> TFS -> get forced to use Git -> roll another of my own
What makes CMS and TFS superior to VSS, Subversion, and Git is Classes (in CMS) and Labels (in TFS). The others do not have an equivalent feature.
TFS also has integrated ticketing and a .net API, which makes it the best system I currently know of.
A feature which CMS (OpenVMS only) has which the others don't is the ability to target multiple libraries (repositories) at the same time -- I wish the others would add that, but they won't. CMS also supports Groups, which the others don't.
HP has again killed the OpenVMS Hobbyist program, so I can't give any demos of how great CMS is.
* I may have mentioned this before. I began it in 2009 (as I recall) and I got it to a vaguely usable state before reaching a major decision point and stalled. The major features are pretty much that of CMS. Occasionally, I think about getting back on it.
|
|
|
|
|
I wish I could say that my experience was that TFS "just worked", because I found the opposite to be true. I've used (and administrated) all of these source control systems:
* Perforce
* ClearCase
* TFS
* git (in CLI and also via BitBucket, GitLab, GitHub)
* svn
* SourceSafe (which is by far the worst of all of these)
* MKS Source Integrity
* PVCS
* CVS
* sccs
* CMS (VAX)
Of these, TFS is a bottom-quartile experience. If you're heavily into the Windows dev train, then it bumps up in usefulness just a hair, but it still sucks. There are 3 items on this list that I'd quit my job over rather than use again, and TFS is one of them.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
