Re: [reSIProcate] major directory reorg
Jason,
While I welcome the reorg because I think it makes more
sense I have a fundamental question. You specifically say
'different repositories' and is where my questions come
from:
- We now have to track commit versions across 5 repositories
to know what is current?
- Symlinks are easy when everything is in trunk and fully
compatible. How is it going to be handled when RESIP
branches and what is required by DUM (and friends) is now a
branch in RESIP and "RESIP trunk" isn't compatible the DUM
trunk or REPRO trunk?
- Is this going to require that ALL new development work be
done in a branch and merged at one time so "trunk" is stable
through the entire lineage? If I want to work with "DUM
unstable" I will checkout RESIP from the top-down then
checkout "dum unstable" someplace to work on it?
The reason I ask is where I work we've been migrating our
CVS and Vss repositories to SVN for about 6 months. We split
some things that "obviously needed to be split" and have had
some versioning hell between a couple packages and
supporting libraries. Part of it is communications and
knowing what is happening but it is also hard to syncronize
multiple groups with different objectives and deadlines.
Just some thoughts...
Jay
----- Original Message Follows -----
From: Fischl jason <jason.fischl@xxxxxxxxx>
To: resiprocate <resiprocate-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [reSIProcate] major directory reorg
Date: Sat, 11 Jun 2005 14:22:05 -0700
> While in Dallas we've discussed a major reorg of the
> directory structure for resip/dum/repro/msrp. Here's the
> plan:
>
> Current:
>
> resip:
> main/sip/resiprocate
> /resiprocate/os
> /resiprocate/dum
> /resiprocate/dum/doc
> /resiprocate/dum/test
> /resiprocate/test
> /resiprocate/doc
> /repro
> /contrib
>
> msrp:
> main/src
> main/doc
>
> Proposed
> Each of resip, rutil, repro, dum, contrib will be a
> different repository. Here's roughly what the intermodule
> dependency is. We'll use symbolic links (in svn) to
> satisfy the intermodule dependencies. If you check out
> repro, it will check out the appropriate dependent modules
> through the sym links.
>
> repro
> |
>
> |---------------|--------------------------|
> dum contrib/db
> contrib/pcre
> |
> resip
> |
> ----------------------------------
> | |
> contrib/ares rutil
>
> resip:
> main/src/resiprocate
> main/src/test
> main/doc
>
> rutil: // resiprocate util
> main/doc
> main/src/rutil
> main/src/test
>
> repro:
> main/doc
> main/src/repro
> main/src/test
>
> dum:
> main/doc
> main/src/dum
> main/src/test
>
> contrib:
> main/contrib
> main/contrib/ares
> main/contrib/db
> main/contrib/pcre
> main/contrib/dtls
> main/contrib/getopt
>
> Implications:
> - break out common utilities into rutil as a separate
> library. - Eliminates the os subdirectory -> will require
> mods to apps - Moves dum to its own module instead of
> subdir of resiprocate -> will require mods to apps
> - symlinks are only supported in subversion >= 1.1
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
>
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel