Timeline for version control security
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot |
Commonmark migration
|
|
| Apr 13, 2018 at 2:26 | comment | added | Marnen Laibow-Koser | @Richard "[In Git] The same diff applied into different files (because they're in a separate branch other changes have also been applied in that branch) is going to give a different id" Well, yes, if you're just throwing patches around. But that's a suboptimal way to use Git. If you have a Git commit whose changes you want to apply to multiple branches, you can (and should) merge that commit into those branches. That will make that commit object (with consistent ID) part of the history of each branch in question. | |
| Dec 9, 2012 at 16:02 | comment | added | Michael Shaw | We manage changes across branches in git using git flow with my current customer. With a previous customer, Accurev has a graphical interface that allows you to see where a particular change has been distributed to. | |
| Dec 8, 2012 at 12:49 | comment | added | Richard | @Ptolemy I can't see how one would do that in Git either. The same diff applied into different files (because they're in a separate branch other changes have also been applied in that branch) is going to give a different id. There is no handle on the change, only on the results of the change: which is going to be different. (If you're two branches are the same – eg. different remote repositories – then you are just saying TFS isn't a DVCS and only in a DVCS can you do "real" change management. This is clearly not a generally held view: CM pre-dates DVCSs for a start.) | |
| Dec 8, 2012 at 11:07 | comment | added | Michael Shaw | Hi @Richard, you are nearly there. The key part is not that a particular change can be applied to multiple branches, but that when a particular change is applied to multiple branches, the fact that it is the same change is known and actively tracked is valuable in change management. This is what TFS does not do. As an aside, because it is not thinking of a file as a changeset, selective merging of changes is problematic in TFS as well. | |
| Dec 8, 2012 at 8:42 | comment | added | Richard | @Ptolemy "TFS cannot support this way of working": I beg to differ. Merge across branches is fully supported. However I suspect you are trying to use TFS as if it were Git, as previously commented that way will not work. | |
| Dec 8, 2012 at 2:10 | comment | added | Michael Shaw | Hi @richard, version control - allows you to manage a linear series of changes to a single file or a directory structure. TFS seems to do this okay. Change management - is where a commit is seen as a first order object, and the software manages how this commit progresses around the branch hierachy, usually in part to do with increasing confidence in the code as it moves through the development branches and test branches onto one or more release branches. You can also track where this commit has been applied, to see if its gone everywhere it should have. TFS cannot support this way of working | |
| Aug 16, 2012 at 11:42 | comment | added | gbjbaanb | @LYQ : no, only VSS has the direct clients accessing the network file system problem. SVN and Git both use a server process to write the data safely using a transaction approach. | |
| Aug 16, 2012 at 11:40 | comment | added | gbjbaanb | I think the problem with TFS is not that its a particularly bad SCM, its that it comes with a load of "workflow" and "enterprise" features that your boss would love (on paper, and never have to use them himself) and devs hate. | |
| Aug 16, 2012 at 8:54 | comment | added | Richard | @Ptolemy I think you might have been reading a little too many anti-TFS pro-DVCS blogs. TFS merge is not as good as Git's. but it largely just works (and has been getting much better compared to the first version of TFS). Unclear what you mean by "change management style", but I've yet to find anything I cannot do in TFS. The right way in TFS is likely to be different (don't try and use TFS as if it were Git/Hg/..., use it as TFS). All this said, if you work for the boss, and the boss really wants to go in one direction sometimes you just need to get on with it. Consider who is paying you. | |
| Aug 15, 2012 at 9:20 | comment | added | Michael Shaw | The most common reason that I've seen companies switch to TFS is because of limitations in VSS (or Vault). They are good reasons to escape from VSS, but TFS is a poor code repository choice too. It's internal data structures make merging more complex for the user than it needs to be, and if you start thinking about code development in a change management style you will need the features of git / Hg / accurev style products | |
| Aug 15, 2012 at 5:17 | comment | added | LYQ | Thank you, @gbjbaanb. "Security" means 1. the access control for the team members. For instance, some of our team members shouldn't have the share/branch permission. 2. preventing unauthorised users from accessing the source code. Can git have the data encyption feature? 3. One of the reasons we concerned about the file system and SQL Server based systems is that VSS is a file-based system. I know a lot of people hate VSS because of its frail database. Will Git and SVN have the same problem? | |
| Aug 14, 2012 at 3:46 | comment | added | Carson63000 | Damn, you have to suspect that there was some trolling of that survey going on if SourceSafe got a vote for "best in class". | |
| Aug 13, 2012 at 9:29 | history | answered | gbjbaanb | CC BY-SA 3.0 |