Re: Promote code feature?

On Tuesday 23 February 2010, saurabh kumar wrote:
> So for example, code starts from being in the Developement server(DEV), and
> then if unit tested ok, it would be moved to QA server, where the Testers
> would test it. Once approved from there it would go to the UA server where
> the customer gets to test it. If approved, the code will finally reach the
> Production/live server.
>
> In version control applications Alfusion Harvest, it can be configured such
> that specific code can ONLY be 'promoted' from within the version control
> from one branch to the other. This way, the developer cannot directly
> commit brand new code directly to a higher level, when it is not in the
> lower environment server yet. This is to ensure, that for example, code
> does not reach production unless it has followed the process of being
> tested via all the lower level regions first.
>
> So, if a user commits file A as version 5 in the DEV trunk. Then, once
> approved, he will be able to ideally click on 'promote' on that version and
> the inventory will be merged in QA branch. The user does not need to have a
> QA working copy on his PC.
>
> This enforces process, and reduces human errors.

A few things here:
1. TortoiseSVN is merely a Subversion client. If you want to enforce anything,
you can not do it client-side, as just switching or hacking the client would
be enough to get around the restrictions. Simply spoken, here is the wrong
place to ask.
2. Subversion offers pre-commit hooks. With those, you can inspect a commit
before it is applied and reject it if it doesn't fit certain criteria. In
this case, you could check that the merge info contains the correct source of
the merges. However, since the changes including the merge info come from an
untrusted user's working copy, there is no guarantee they are correct and
resemble what you actually want to enforce.
3. Subversion doesn't support merging without intermediate working copy, so
that would have to be emulated. Since merges can conflict, you need a
conflict resolution plan, which typically involves a use with special
privileges.

What you can still do is to layer a similar system on top of Subversion. How
much and how far depends on how much you want to "enforce" (as opposed
to "guide") people to follow these steps. In any case, asking on the
Subversion mailing list would get you further than here probably.

Uli

-- 
ML: http://tortoisesvn.tigris.org/list_etiquette.html
FAQ: http://tortoisesvn.net/faq
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
           Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2450978
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].