Hi, Jason,
Thanks for the feedback. Based on your subsequent off-list message,
it sounds like we're really converging on a mutually agreeable
migration plan. I think the disposition of /trunk/roach is the main
area left for further discussion, though (for the benefit of the
casper list readers) I think we're in closer agreement on that than
your initial comments below imply. I'll defer responses on that
topic to the off-list thread.
On Jun 2, 2010, at 0:31 , Jason Manley wrote:
Presumably you'll migrate the new ROACH2 SVN to a different GIT
repo too?
Where is the new ROACH2 SVN repository?
Are we going to separate the casper_library into multiple sub-
library files? If so, we can easily pull-in the gavrt library with
minimal changes. It might be nice to merge this into mlib devel's
structure though (eg put the accumulator with the other
accumulators so that people can find it).
The separation of casper_library into multiple sub-library files is
independent of the migration to git. While I think it would be a
very good idea, it need not happen before the migration. It might be
best to defer that until after the migration to limit the amount of
change happening at the same time.
The gavrt_library represents a slight challenge in that it is
included in mlib_devel_10_1 by way of an svn:externals property.
Since it is really just a link back to trunk/caltech/lib10.1 in the
same repository, I think the only effect of including it as an
svn:externals is that it gets checked out along with an
mlib_devel_10_1 checkout into the gavrt_library subdirectory. I
think there are three possible ways of dealing with this (listed in
my order of preference)...
1) Move the stuff in trunk/caltech/lib10.1 into mlib_devel_10_1
proper and be done with it. This will lose the history of those
files, but there's not much history to start with so it's not really
a significant problem.
2) Migrate trunk/caltech/lib10.1 to its own git repo and let users
get it separately (i.e. in addition to the mlin-devel repo).
3) Migrate trunk/caltech/lib10.1 to its own git repo and setup a git
submodule in the mlib_devel repo to mimic the behavior of svn:externals.
Dave
