You bring up a good point about the pre-commit code review process.  I have 
never been in an organization that had strict pre-commit code review 
requirements so it wasn’t an issue.  To me, so much of it just comes down to 
the developer.  We have been doing interviews of Junior engineers and asking 
them the question “assume you have a Git repository, if you have local changes, 
and you need to get changes from master into your branch, what do you do?”  The 
answer is surprisingly common to just make a local copy on the file system, 
reclone the git repo and then move the changes over manually….I cringe every 
time I hear that one.

Regarding the merge tracking that wanted to be added, what end user 
functionality would that add?  From my understanding through reading the docs 
and this earlier conversation, I thought that most of the merge tracking issues 
had been resolved?

> On Oct 29, 2021, at 12:36 PM, Mark Phippard <markp...@gmail.com> wrote:
> 
> On Fri, Oct 29, 2021 at 1:26 PM Luke Mauldin <lukemaul...@icloud.com> wrote:
>> 
>> Sorry to hear about the Teams / Sharepoint migration, that seems to be 
>> occurring industry wide.  “Its moving to the cloud so it has to be better”.  
>> It also amazes me how much money and labor large companies are throwing at 
>> Git to have it scale to scenarios that it was never envisioned to support 
>> but every company has to be on Git because “thats what the developers want”. 
>>  Every company that I have worked for that has used Git has always had a 
>> centralized Git repository just like SVN. From the SVN community’s 
>> perspective, I am curious to see their perspective on why the industry 
>> transitioned away from SVN to Git?
> 
> 
> In my experience, it is the code review and branching workflows that
> git enables that wins the day, With SVN the pre-commit review process
> is too cumbersome and there is no real guarantee that what was
> committed is what was reviewed. There have been several good solutions
> for this built on Git, with the GitHub Pull Requests being the most
> notable.
> 
> In environments where pre-commit code review is not part of the
> culture or process I find it hard to beat the SVN workflow for ease of
> use. Conceptually, I have always liked the way SVN models a versioned
> file system but it has also been the achilles heel when it comes to
> using folders to model branches and tags so that neither of those
> features truly exist in SVN and are really more conventions that one
> can adopt in the folder structure. SVN's extreme flexibility has also
> made it difficult to develop some of the features we wanted like merge
> tracking because it became an endless slog of dealing with weird edge
> cases.
> 
> Mark

Reply via email to