4 ms·

I've used git on several hosts and subversion back in the day. I have no problem learning new things. Tortoise, bitbucket, github, beanstalk to name a few. I t

I've used git on several hosts and subversion back in the day. I have no problem learning new things. Tortoise, bitbucket, github, beanstalk to name a few. I think your reaction is more horrifying than me not having a compelling reason to change the way I've been doing things without flaw for decades.

Aloha 11y ago
So long as it works for you, thats great - I just hope you have a migration path if/when it stops working. I do however get the objection to newer is better, I keep getting besieged to move my projects from svn to git - to which I usually respond "Why, tell me what feature we need in git, that svn doesn't do?" I've yet to get an answer.
- supercoder 11y ago
  Non centralized is probably the best one. But agree it's harder from there.
- cesarb 11y ago
  If you "keep getting besieged to move [your] projects from svn to git", I can guess that who is asking is probably downstream consumers of your projects. What they might actually be wanting: - Familiarity. Everyone uses git nowadays; like it or not, svn projects are the odd ones out. - Fast, offline querying of the project's history. With git, they have a full copy of the project's history in their local computer, while with svn, any query has to go to the server. This helps a lot when chasing regressions, or just when browsing the changes between one release and the other. - Easy branching. Branches in git are more lightweight than branches in svn, and git's merge functionality is quite good. When they want to propose some change to your code, they can just create a branch in their local copy, make the changes they want, publish the branch somewhere, and ask you to merge it; this is made even easier by sites like github. With svn, unless they have an account in your svn server, they have to do it the old-fashioned way.
  - Aloha 11y ago
    I'm effectively using SVN as a CMS in this case - its just an easy way to sync files between workstations.
sk5t 11y ago
I'm not trying to be mean. If one is going to stick with an obsolete source control system--as an important part of one's work process--there should be a good reason for doing so; however, one cannot make such a justification based on ignorance of the alternatives unless the two hours to learn, e.g., git, cannot be spared and would not be recouped in future productivity.

Aloha 11y ago

So long as it works for you, thats great - I just hope you have a migration path if/when it stops working. I do however get the objection to newer is better, I keep getting besieged to move my projects from svn to git - to which I usually respond "Why, tell me what feature we need in git, that svn doesn't do?" I've yet to get an answer.

supercoder 11y ago
Non centralized is probably the best one. But agree it's harder from there.
cesarb 11y ago
If you "keep getting besieged to move [your] projects from svn to git", I can guess that who is asking is probably downstream consumers of your projects. What they might actually be wanting: - Familiarity. Everyone uses git nowadays; like it or not, svn projects are the odd ones out. - Fast, offline querying of the project's history. With git, they have a full copy of the project's history in their local computer, while with svn, any query has to go to the server. This helps a lot when chasing regressions, or just when browsing the changes between one release and the other. - Easy branching. Branches in git are more lightweight than branches in svn, and git's merge functionality is quite good. When they want to propose some change to your code, they can just create a branch in their local copy, make the changes they want, publish the branch somewhere, and ask you to merge it; this is made even easier by sites like github. With svn, unless they have an account in your svn server, they have to do it the old-fashioned way.
- Aloha 11y ago
  I'm effectively using SVN as a CMS in this case - its just an easy way to sync files between workstations.

sk5t 11y ago

I'm not trying to be mean. If one is going to stick with an obsolete source control system--as an important part of one's work process--there should be a good reason for doing so; however, one cannot make such a justification based on ignorance of the alternatives unless the two hours to learn, e.g., git, cannot be spared and would not be recouped in future productivity.