Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Andreas, > > policy implementation). If the corporate policy is to NOT allow you > > access to write that file - then that's the policy. > > That's why I need to find someone else who is able and can be > convinced to do the commit for me. That is just circumventing the policy. An auditor finding that this happened would fail the process and any company using this process would lose accreditation. We go though this in our CM Design course: what you are attempting to do in an unmanaged way should be managed by the CM tool and CVSNT has all the functions necessary to manage it. For instance: you can check in, but then a person with seniority is responsible for promoting the change from 'dev' to 'approved' (or 'code review). > If I'm not allowed to commit a change, > that does not mean that it is forbidden that I pass on > the change to another person who is allowed, and the tool > should enable me to do so. If you were authorised then you would be authorised ;) This is a fantastic example of the difference of thought processes between a project manager and a programmer. A programmer thinks it can be solved with a program, a manager looks for how it can be better managed or if it is intentionally unmanageable. Saying that your employer has refused to give you write permission to a file but it is OK to author a change and give that change to someone else who does have permission to write is like saying that I don't have permission to keep this DVD I rented from blockbuster but I can always just duplicate it and keep the copy: of course it's technically possible, but I am not authorised. > Where is that bleeding edge? So far I failed to notice anything > like research in that area. You need to read CM articles and journals and newsgroups that are not about specific tools but about CM theory and generic implementation. > We have used cvs and then cvsnt, and started to think seriosly about > switching to svn two years ago, and then still waited until svn 1.5 > came out -- we didn't want to do without merge support. If the migration of the 'legacy' CVSNT system to SVN has not delivered all the expected BENEFITS but you have still obtained all the COSTS of migration then it's likely been an expensive exercise, though based on an article on the valuation of IT assets published in The Financial Times UK Edition 36,501 on Monday October 1 2007 it is likely your organisation hasn't measured those costs. The article talks about the lack of business cases for the benefit of software and also the business case for maintaining legacy assets - you may want to obtain a copy or of the full whitepaper. What has your employer learnt about valuing your IT assets (like CVSNT) and how to perform a risk assesment and cost benefit assesment about migrating from legacy systems in the future? In short - I know you think GIT is great, but presumably you also thought SVN was great before you began a wholesale migraion. What planning process are you putting in place to ensure that exactly the same thing doesn't happen when you migrate from SVN to GIT? All the COSTS but not the BENEFITS? This is why we wrote EVS, this is it's justification: one system - many workflows - open clients. I'm interested to know why your organisation thought about switching (to SVN) at all? What tangible measurable benefit did you expect to gain? When you realised that the benefit wasn't there (which I'm assuming based on comments in this thread) did you do (stop and return to CVSNT?)? Regards, Arthur Barrett