[OWASP-ESAPI] OWASP-ESAPI Digest, Vol 26, Issue 20

Mon Nov 9 15:26:37 EST 2009

All,

As someone who has not committed yet, I don't expect to have any  
voice. So, take all this with the appropriate grain of salt ;-)

...Kevin suggested that Google Code as a big driver and as such the  
choice becomes CVS or SVN. Yes, CVS is just short of useless. Still,  
looking at things from a services perspective: Google Code doesn't  
seem to provide much differentiated services (you basically just need  
disk, HTTP, bug/feature tracking, and forums). It seems to me that if  
ESAPI is used by organizations, managing branches will be your long- 
pole, not disk or web-server capabilities. Having solved the merge  
problem before it becomes prevalent (though, not now) is advisable, I  
promise.

Mercurial  (suggested below) interests me. I looked at it for my own  
project. Mercurial, in particular, performs better than GIT for what  
we ended up calling 'partial-checkouts' (circumstances when you wanted  
to checkout, manage, then merge a sub-project in -- such as Java EE  
Canonicalization only). I confess, however, I've not done a lot of  
merging with it yet, at least not across organizations.

Certainly Craig, I agree with your branching philosophy. However,  
adhering to it quickly shows one SVN's limitations. You wouldn't  
believe how many utilities I have to govern SVN's bull. My favorite?  
One encapsulating svn log --stop-on-copy (which helps one figure out  
the revision for the source-branch on a merge--though not obvious from  
the command itself). Isn't that what the version control software is  
supposed to handle under the covers for me?

Regarding which is better for ESAPI (Mercurial or GIT), I can't say  
definitively.  I do predict that success will victimize each persona's  
maintainer where SVN is used.

-jOHN

On Nov 7, 2009, at 3:57 PM, Craig Younkins wrote:

> +1 for the distributed model of SCM, but git may not be the best  
> choice for a couple reasons. First, Windows support is not very  
> good. It came out of a need for Linux kernel source management after  
> all. Second, it is not supported by Google Code, where most if not  
> all ESAPI projects are hosted.
>
> I strongly recommend Mercurial (http://mercurial.selenic.com/) for  
> it's great cross-platform support and integration with Google Code.  
> It's similar to git in design and capability. I'm using it for ESAPI  
> on Python, and have been very happy with it.
>
> Commit often and remember where you were. Make use of branches to  
> hack out features in parallel, and easily merge the branch back in  
> to trunk. Check out Mercurial. You'll be glad you did.
>
> --
>
> Craig Younkins
> Mobile: (301) 520-0463
> Website/Blog
>
>
> On Fri, Nov 6, 2009 at 3:15 PM, John Steven <jsteven at cigital.com>  
> wrote:
> All,
>
> I don't know how long you've been using SVN or what major/minor  
> version you're relying on for front-/back-end work but I've been  
> using SVN for my projects for a few years and run into many problems  
> I'd have avoided if I went to GIT earlier on.
>
> In particular, when people did local repository caching and complex  
> branching merger became difficult or impossible. Wichers personally  
> witnessed a bleary-eyed jS laid-over in Frankfurt fighting to merge  
> (local) repository X bug-fixes into (master) repository Y, over  
> borrowed Innanet time. You may have already struck some of the  
> problems because you haven't had to do cross-repository syncing with  
> adopting clients who are stuck at a previous major release (or  
> similar). These things get nasty quickly.
>
> Whereas I would never suggest you move to a new repository format /  
> product so close to a release, I might suggest you wet feet and whet  
> appetite with GIT in the meantime and spent as little time marrying  
> deeper into the SVN family of tools/problems. This is what i'm doing  
> for my projects anyways.
>
> ----
> John Steven
> Senior Director; Advanced Technology Consulting
> Desk: 703.404.9293 x1204 Cell: 703.727.4034
> Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908
>
> Blog: http://www.cigital.com/justiceleague
> Papers: http://www.cigital.com/papers/jsteven
> http://www.cigital.com
> Software Confidence. Achieved.
>
>
> Message: 2
> Date: Fri, 06 Nov 2009 12:48:13 -0700
> From: Neil Matatall <neil at owasp.org>
> Subject: Re: [OWASP-ESAPI] Help needed building OWASP ESAPI from
>       source using Eclipse
> To: "Kevin W. Wall" <kevin.w.wall at gmail.com>
> Cc: owasp-esapi <owasp-esapi at lists.owasp.org>
> Message-ID: <4AF47D7D.8080802 at owasp.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I'm very aware of the two clients and often switch between the two  
> when
> one fails me ;)
>
> I'm currently using Subversive, which I believe is becoming more of  
> the
> standard as new versions of EE Eclipse come with the repository out of
> the box.  Also, it has a few more features that are nice, but not
> necessary.
>
> Should the guide go into such detail?  Is it sufficient to simply say
> "install an Eclipse SVN client and check out the project"?  There are
> plenty of tutorials for doing just this and as mentioned before,  
> that's
> just one more thing to maintain.
>
>
> So, ESAPI poll:  subclipse or subversive?   Just curious.  The  
> debate is
> always on, but I'd be interested to what a group of developers more  
> like
> myself use.
>
> Neil
>
>
>
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20091109/2b950577/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4359 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-esapi/attachments/20091109/2b950577/attachment-0001.bin 