Re: [reSIProcate] major directory reorg
After even _more_ discussion (I first participated in this today), the
thinking is to follow proposal 1 _except_ that we'll keep MSRP in its
own subversion repository.
We will continue to discuss whether it makes sense to put repro
in its own repository.
Keeping rutil inside the same repository as resiprocate and dum
makes sense. (Though we might _release_ it in a separate tarball).
I'm going to create a branch to start experimenting with this
reorganization in.
RjS
On Jun 12, 2005, at 3:29 PM, Fischl jason wrote:
After much discussion in Dallas, here is take 2 on reorg plan. The
previous proposal had an issue where revision numbers could not be
common across the different projects. Here are two proposals that
address this. Mostly this involves directory restructuring and
importing msrp into the same subversion module as the other projects.
Proposal 1:
main/build
/autotools
/contrib
/resiprocate
/resiprocate/doc
/resiprocate/test
/dum
/dum/doc
/dum/test
/rutil
/rutil/doc
/rutil/test
/repro
/repro/doc
/repro/test
/msrp
/msrp/doc
/msrp/test
- this is relatively close to what we have now in that the source
files are in the first subdirectory. e.g. in main/resiprocate
- complaint is that the README file, doc and test directories are hard
to find amongst the source files
- eliminates the "sip" directory
Proposal 2:
main/build
/autotools
/contrib
/resiprocate/src
/resiprocate/doc
/resiprocate/test
/dum
/dum/src
/dum/doc
/dum/test
/rutil
/rutil/src
/rutil/doc
/rutil/test
/repro
/repro/src
/repro/doc
/repro/test
/msrp
/msrp/src
/msrp/doc
/msrp/test
- also eliminates the sip subdirectory.
- requires third party applications to run make install to have access
to project header files
On 6/12/05, Jay Hogg <jay@xxxxxxxxxxxxxx> wrote:
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
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel