[Vtigercrm-developers] Trees in SVN (Was: SVN access)

[Sergio A. Kessler]

yup, that sound very good...

devel.vtigerforge.com with trac & SVN hosting v5 & v4.2

www.vtigerforge.com with gforge & another SVN repo for the thirdy
party projects...


/sak

On 2/4/06, Jeff Kowalczyk <jtk at yahoo.com> wrote:
> (sorry, this reply is going to arrive out of thread)
>
> Mike Fedyk wrote:
> > Then what does www.vtigerforge.com do then?
> > devel.vtigerforge.com should be for the trees currently in development.
> > Not the current stable release.
>
> Just wanted to see if this was a commonly held expectation...
>
>
> Development on vtigercrm/trunk, Maintenance on vtigercrm/branches/4.2
> ---------------------------------------------------------------------
>
> I thought the subversion repository and trac instance (whatever its final
> domain name and physical host) is intended to be used for all vtiger-branded
> development. This means any bits that vtiger-the-company will put their name on
> and release.
>
> I include stable, maintenance and pre- releases in that category, and they'll
> all be found under vtigercrm/tags, starting with accurate recreations of
> vtigercrm-4.2.3 and vtigercrm-5.0.0-alpha1 tags.
>
> The branching and merging features of subversion are intended to be used within
> a single repository. If maintenance branches and development trunk weren't in
> the same repository, there wouldn't be much point in the exercise. It would be
> a significant step back from where we were with CVS, actually.
>
> Excerpted from "Getting svn checkouts, making commits"
>
> 5.0 development is happening on the trunk:
>  svn co http://vtiger.fosslabs.com/svn/vtiger/vtigercrm/trunk vtigercrm
>
> 4.2.x maintenance is happening on a branch:
>  svn co http://vtiger.fosslabs.com/svn/vtiger/vtigercrm/branches/4.2 vtigercrm
>
>
> Forge in separate repository
> ----------------------------
>
> A second subversion repository would be made available on the same host for
> third-party projects related to vtiger. This can have looser requirements for
> getting commit access, etc. Since trac is single-project-oriented, it is likely
> that the (gforge) software will be better suited for the web-UI to that
> repository.
>
>
> Authenticated access == Go live date
> ------------------------------------
>
> I think that's where we're headed, right? When svn+ssh or https authenticated
> access is opened, I presume the recent trunk checkins will be manually replayed
> into this repository by the core devs, and then sourceforge CVS just goes dark,
> as a matter of policy.
>
> BTW, svn repositories can be moved to other machines easily (svn dump, svn load).
>