SVN workflow
-
In continuation with my last post - Integration hell[^] I agree with you all that more than anything it's a workflow issue and now finally I have taken out time to fix the workflow issue once and for all. I am going through various documentation about SVN workflow best practices and a bit confused what should be the ideal structure. First I will explain our development environment - 5 developers working from one location and 4 developers working from offshore location. Apart from this 2 product managers may need to push small css changes every now and then like colour change etc Now my questions are: 1. Should I really consider distributed version control like GIT or stick to SVN as other team members are familiar with SVN more than GIT. So there will be learning curve for all if we switch to GIT also server is all set up for SVN so bit of cost issue as well. But if it really adds value (like merging is way more easy in GIT) then I am sure I can try to convince to move to distributed version control. 2. If I stick to SVN what is the recommended way to structure Trunk, Branch and Tag? Thanks for all your help.
-
In continuation with my last post - Integration hell[^] I agree with you all that more than anything it's a workflow issue and now finally I have taken out time to fix the workflow issue once and for all. I am going through various documentation about SVN workflow best practices and a bit confused what should be the ideal structure. First I will explain our development environment - 5 developers working from one location and 4 developers working from offshore location. Apart from this 2 product managers may need to push small css changes every now and then like colour change etc Now my questions are: 1. Should I really consider distributed version control like GIT or stick to SVN as other team members are familiar with SVN more than GIT. So there will be learning curve for all if we switch to GIT also server is all set up for SVN so bit of cost issue as well. But if it really adds value (like merging is way more easy in GIT) then I am sure I can try to convince to move to distributed version control. 2. If I stick to SVN what is the recommended way to structure Trunk, Branch and Tag? Thanks for all your help.
We have now the same issues somehow. It is getting clearer, that Git wins because it has more advantages because branching and merging is better. And rebasing cleans up with messie trees. Our tree will be more like different developments trees (sprints) and a master tree, which will get tags. After some discussion we are convinced that branching is temporary because every branch gets (somehow) merged in the master.
Press F1 for help or google it. Greetings from Germany
-
In continuation with my last post - Integration hell[^] I agree with you all that more than anything it's a workflow issue and now finally I have taken out time to fix the workflow issue once and for all. I am going through various documentation about SVN workflow best practices and a bit confused what should be the ideal structure. First I will explain our development environment - 5 developers working from one location and 4 developers working from offshore location. Apart from this 2 product managers may need to push small css changes every now and then like colour change etc Now my questions are: 1. Should I really consider distributed version control like GIT or stick to SVN as other team members are familiar with SVN more than GIT. So there will be learning curve for all if we switch to GIT also server is all set up for SVN so bit of cost issue as well. But if it really adds value (like merging is way more easy in GIT) then I am sure I can try to convince to move to distributed version control. 2. If I stick to SVN what is the recommended way to structure Trunk, Branch and Tag? Thanks for all your help.
Where I work, we used a versioning tool similar to SVN and then we transitioned to GIT mainly due to reliability issues in the tool we used but also somewhat due to merging issues. The learning curve for most of us was steep and there was a lot of training given. For the most part, it seems that we are getting better at using GIT. One of the big advantages is the submodule functionality so that multiple projects can reuse one submodule which may be at different branches at different times. So that allows us to consume submodule changes only when we want to. Things that GIT doesn't do too well: 1. History is important to us and the GIT merge feature basically rewrites history. So we decided to use only use rebase. 2. We have also had problems when rebasing on top of large number of changes. GIT did not merge/rebase correctly and it didn't give any indication that something went wrong. 3. GIT does not handle binary files very well - uses more space 4. It often happens that 2 developers try to rebase and push their changes at the same time and when pushing, they get an error that their branch is out of date and so they have to do that whole process again. After doing that a few times, I have abandoned the practice to make sure that everything still compiles before pushing. This has resulted in some build instability (not only due to me ;) ) 5. It is not easy to find what version of a given file is actually included in a given build without first checking out to the SHA-1 of that build. This is more of an annoyance because you may need to check something while you are in the middle of modifying files. One of my pet peeves with GIT is that you can't tell from two SHA-1's of a file, which is the earlier version. Having said all that, I would tend to stick with SVN for your situation but that may just be that I'm old school :-D With regards to the Trunk, Branch and Tag, I would only use a separate branch if there would be a lot of changes made before a new release is ready for the production server. We used a 'development' tag to indicate that a particular file was locally tested and deemed fit for production. This tag is then used to build a stable version of code. Changes could be made to the file and checked in but the development label would not be pulled up until local testing (whatever that entails) has been completed. I hope this long-winded response helps. All the best with the decisions you need to make.
-
In continuation with my last post - Integration hell[^] I agree with you all that more than anything it's a workflow issue and now finally I have taken out time to fix the workflow issue once and for all. I am going through various documentation about SVN workflow best practices and a bit confused what should be the ideal structure. First I will explain our development environment - 5 developers working from one location and 4 developers working from offshore location. Apart from this 2 product managers may need to push small css changes every now and then like colour change etc Now my questions are: 1. Should I really consider distributed version control like GIT or stick to SVN as other team members are familiar with SVN more than GIT. So there will be learning curve for all if we switch to GIT also server is all set up for SVN so bit of cost issue as well. But if it really adds value (like merging is way more easy in GIT) then I am sure I can try to convince to move to distributed version control. 2. If I stick to SVN what is the recommended way to structure Trunk, Branch and Tag? Thanks for all your help.
Give me good old PVCS, lock those files to make sure no one else can screw around in where you are working. Half serious, but then I don't like change. If you go to Git use either SourceTree or GitKraken, the GitHub windows app hides way to much of the functionality.
-
In continuation with my last post - Integration hell[^] I agree with you all that more than anything it's a workflow issue and now finally I have taken out time to fix the workflow issue once and for all. I am going through various documentation about SVN workflow best practices and a bit confused what should be the ideal structure. First I will explain our development environment - 5 developers working from one location and 4 developers working from offshore location. Apart from this 2 product managers may need to push small css changes every now and then like colour change etc Now my questions are: 1. Should I really consider distributed version control like GIT or stick to SVN as other team members are familiar with SVN more than GIT. So there will be learning curve for all if we switch to GIT also server is all set up for SVN so bit of cost issue as well. But if it really adds value (like merging is way more easy in GIT) then I am sure I can try to convince to move to distributed version control. 2. If I stick to SVN what is the recommended way to structure Trunk, Branch and Tag? Thanks for all your help.
We ditched SVN a few years ago and moved to Git. I'd never go back. The transition was smooth, the learning curve surprisingly un-steep (admittedly we use very few features) and Visual studio 2015 support totally adequate.
cheers Chris Maunder
-
Give me good old PVCS, lock those files to make sure no one else can screw around in where you are working. Half serious, but then I don't like change. If you go to Git use either SourceTree or GitKraken, the GitHub windows app hides way to much of the functionality.
I'll never go back to file locking, but I do admit that the current development group I work with has no idea how to do a merge operation.
Charlie Gilley Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759