On 01/08/09 09:18, "Michael McCracken" <michael.mccrac...@gmail.com> wrote: > On Thu, Jan 8, 2009 at 10:13 AM, Adam R. Maxwell <amaxw...@mac.com> wrote: >> Just as a note, it might be easier for others to contribute if some >> ground rules were agreed on (maybe better late then never...). I quit >> because development is anarchic: anyone can rewrite anyone else's code, >> regardless of whether it's a work-in-progress, so it's difficult to >> build or design anything long-term. Additionally, there is no review >> process, just watching the commit list and arguing after the fact. > > This is one reason why git-svn is interesting. git would let us > maintain local changes under version control without changing the > "official" mainline build in SVN until after discussion of a change.
So you hack on a local copy and commit to a local git repository, then sync with the remote svn repository when you're done? I never bothered installing git, since IIRC it dumps a huge number of tools on your drive. Would this be worth using for "small" changes, or mainly for something massive like a rewrite of file handling? What I've done for a long time is keep a bibdesk-clean (for nightly builds) and bibdesk-working, where I hack on stuff that's not ready for commit. And I use Undo a lot in Xcode :). It's pretty hard to tell when something's ready for commit, and I think we all have different ideas on that; that's basically the problem I have. So how do /you/ tell if it's time to check in? 1) the code looks like it would compile 2) Xcode syntax highlight doesn't show any errors 3) would have compiled except for a misnamed variable 4) actually compiled without errors or warnings 5) the program launched 6) launches and can still open a file 7) launches and new feature/fix seems to work 8) launches and other features affected by feature/fix still work All of the major contributors (myself included) have checked in stuff that covers the full range. I recall a couple of times I've lost data from untested changes to BibItem, and that's particularly dangerous now with nightly builds. Screwing up others' data makes them irritable (my botched attempt at escaping &~% in character conversion comes to mind...). If it's a 1-3, it's obvious that 5-8 aren't guaranteed. Committing at 7-8 reduces frustration for others and keeps from wasting their time...but it takes more time up-front for the committer. Having at least a tacit guarantee of testing before commit makes it easier for people to contribute (just my opinion). regards, Adam ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
