On 29/03/06, Damphyr <damphyr@freemail.gr> wrote:
> James Courtier-Dutton wrote:
> > On 29/03/06, Lakshman Srilakshmanan
> > <lakshman.srilakshmanan@tradingpost.com.au> wrote:
> >> Hi James,
> >>
> >> Using a version control system to determine/manage what should be
> >> released to a customer (release control) may not necessarily be the
> >> right way of doing it.
> >>
> >> I use a release script (ie ant) to create a release directory and
> >> prepare it for release to
> >> the customer. This script is modified for every release and versioned
> >> controlled.
> >>
> >> This ensures that there is little room for error. Every time you
> >> checkout a "Release Tag", you are able to reproduce the release package
> >> as it appeared in the original release.
> >>
> >> Thanks
> >> Lakshman
> >>
> >
> > To put this in context, the feature I describe is in a package called
> > ClearCase. http://www-306.ibm.com/software/awdtools/clearcase/
> > I am trying to get svn to mirror some of the features of ClearCase,
> > and this "views" feature is a way to have a view of a potential
> > release as it is nearing release, but still changing.
> >
> > I could add this feature to svn, but I don't really want to try unless
> > svn developers think it is a good idea.
> >
> > As for release control, release control is just a "process", with
> > things like svn just being tools in that process. If a tweek to svn
> > could make the process more efficient, then I think it would be worth
> > doing. I believe that my suggestion of labels and views would result
> > in you not needed any "release scripts", so surely that would make
> > things more efficient for you also.
> >
> > James
>
> ClearCase views are a very different beast to tags. I guess what you do
> is you label a set of files and then use a CC view (probably a dynamic
> one, which in itself is a very confusing and ineffectove thing) to
> always have a copy of the label. A CC view is a subversion working copy.
>
> Clearcase is overly complex in this regard and mixes a lot of
> conventions and paradigms. My experience with it is that it only
> confuses your developers, your release manager and almost everyone
> involved (and I used and ended up administering a large CC installation
> for more than 4 years - I would have substituted the whole beast for a
> single subversion server if they had let me).
>
> What you want is a working copy of a branch, where you merge the
> per-customer changes.
> It does the same thing with the label/view paradigm of Clearcase and it
> can't be abused as much (I don't know about you, but I have had lots of
> overtime fixing things because some idiot thought it good to move a label).
>
> I would advise you to stop trying to mimic CC's behaviour and adapt to
> Subversion's paradigms. They're cleaner, simpler and in the end a lot
> more effective.
> Cheers,
> V.-
>
Maybe I did not make myself clear. I am against CC as much as you are.
Here is an example of my requirement.
13 files in the repository.
10 files must go to customer A
8 files must go to customer B
5 files common to both.
So, if one of those common files change, both customers must receive
the same change.
I do not want to have 2 working copies, one for A and one for B, and
have to continually merge changes from one to the other. I would like
the fact that I change one of the common files and commit it, it will
automatically update both A and B views of the repository.
Kind Regards
James
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 29 13:48:34 2006