[Info-vax] Where to locate software

[Johnny Billquist]

On 2016-06-16 15:33, Craig A. Berry wrote:
> On 6/16/16 4:24 AM, Johnny Billquist wrote:
>
>> The distinction between committing and publishing on the other hand is
>> not really anything that impress me. It's more a crutch for people who
>> are afraid to commit.
>
> People should be afraid to commit. They should review and revise their
> code, make sure it passes tests, add more tests, reread and edit their
> commit messages, think about the order and coherence of the commits
> (changesets) and whether they preserve bisectability, all before
> considering the code finished and ready to publish.

That is something I totally disagree with. The whole point of version 
control systems is so that you can do changes and easily go back and 
forth between versions, and if you did something wrong it is not a 
catastrophe. Your attitude really reflects the pre VC era.

What you talk about are appropriate for when you are going to do a 
release, which is a different process than development.

When people start treating VC systems as something to be afraid to use, 
then the world have totally failed!

> I had a professor in graduate school who joked that he'd spent
> twenty-five years perfecting the skill of typing a clean first draft on
> a typewriter but the advent of the word processor had ruined it all for
> him. Resistance to local commits is pretty much the same attitude;
> people have had to work a certain way because of the limitations of the
> available tools, so tools without those limitations just feel wrong.

What you are describing your professor doing sounds exactly the same as 
what you were describing yourself in the previous paragraph - about 
@review, revise, test, more tests, reread and edit, and all kind of 
work, before doing a commit. Just like your professor. Perfecting the 
skill of the perfect, clean draft, before committing.

A horrible approach, if you ask me.

>> But the talk about creating a changeset without contending with other
>> users users changes more sounds like you have not understood branches.
>>
>> Or I could ask it this way: what contention???
>
> I believe I said something up-thread about having to choose between a
> branch per developer and a branch per feature. I guess you could have
> one for each combination, in which case you can avoid contention. But
> usually there is a feature or release branch with multiple people
> working on it. And so to push your changes you have to stop what you're
> working on and deal with any conflicting changes others have made right
> then and there. Of course on very small teams, the contention may not
> come up often enough to be worth bothering about.

You can do whatever works best, for what you are doing. And I totally 
fail to ever see what the contention is about.
If you are cooperating on some change then you want to see and 
incorporate their changes, so you keep on the same branch. If you want 
to do some fiddling of your own, you create a branch of your own, do 
your work, and when you are happy, you merge it back up, at which point 
others have to incorporate it. And that, in turn can be a branch in 
itself. No need for full matrixes ever. You do what makes sense, and 
don't try to just do silly things for some principle.

	Johnny