[EHPweb] EHP and SVN

[Michelle Guy]

Eric,
good proposal.  a few minor things for consideration:
1) under phase 2 where you list the directyory structure for SVN repository,
in addition to www and apps you might want to consider a 3rd type called
libs or utilities, where libs or utilities refers to code or scripts or
whatever that can be used by apps and www, for example code that converts
UTC date time to epoch seconds, etc.  i'm not suggesting you create anything
currently (unless it exists) just suggesting mentioning it in the proposal
as an option.
2)under release cycles item II.B.3 i recommend planning to merge these level
of fixes out to development branches as well
3) under release cycles item III and IV may want to add a final step to each
of these release processes to run a validation check to confirm that the
release worked (i.e hit the public website), this might be obvious, but good
to list out all the steps in the process just to be clear.
4) under critical and time-dependent modifications similar to item 2 i
mentioned above, i recommend mergin these kind of fixes out to development
branches as well.  i recommend merging out to development sooner rather than
waiting for development to complete and then trying the merge as the longer
the files have to diverge the more potential for merging conflicts.  but
this can also be assessed on a case by case basis.  however merging these
fixes out to development branches may also prevent duplicate debugging from
occuring on dev branches when the problem has already been fixed on the
trunk.

this last item leads me to a very minor thought relative to what is on the
trunk versus what is on a branch, and maybe comes down to just a terminology
issues.   but just to share a different perspective, we made the trunk of
our respository be the development code, such that if you get the "head" of
the trunk you always get the latest and greatest code (which may or may not
work because it is development).  and then we create tags on the trunk for
releases.  and then if a release needs a fix made to a file that has already
been modified for future development tasks (thus cannot be released) then we
create a branch from that tag and make the mod's for the release on the
branch.  and then merge the release fix into the trunk (development)
code. our theory is that development is on going and is dynamic (always
changing) and is the core of what we do as, thus the trunk.  releases become
static and are not changing, and eventually become historical and thus "end"
(so to speak), so they are the branches.

hope that helps.  oh and regarding seeing our dev tools (repository, wiki,
bug tracking, etc), i don't have an office this week so i am working out of
our dev lab, which is also moving by the end of this week, so it's rather
touch and go for me this week.  would it still be helpful to show you our
stuff next week say maybe on tuesday afternoon?

michelle

On Tue, Aug 5, 2008 at 2:21 PM, Eric Martinez <emartinez at usgs.gov> wrote:

>        We've been trying to come up with a set of procedures for developing
> and maintaining new and existing web content and applications.  Attached is
> a draft proposal for this.  Please read and let me know what you think.  It
> necessarily adds overhead to development, but gains robustness, stability,
> and integrity.  This is a very rough draft so please feel free to contact me
> with comments, questions, concerns, or suggestions.
>
>
>
>
>
> Thanks,
>        ~Eric.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://geohazards.usgs.gov/pipermail/ehpweb/attachments/20080805/af702dc5/attachment.html