On Fri, Jan 9, 2009 at 1:23 PM, Maxwell, Adam R <adam.maxw...@pnl.gov> wrote: > 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.
That's right. I also haven't installed git. I've used darcs and arch, though. most examples of git I see now have a single executable "git" so you say "git add" now instead of "git-add" - don't know if that means it now only installs one binary though. > Would this be worth using for "small" changes, or mainly for something > massive like a rewrite of file handling? Either. Small changes are fine. I like small commits, since it makes tracking history easier, and a quick diff against the last local commit is a great way to find temp testing code that should not be committed to the main, because it'll be smaller than looking through the whole patch. I *believe* git also has a feature I loved in darcs: say you make two separate unrelated changes to a file, like a bug fix in one function and a feature add in another. You then go to commit. In SVN, you get one commit with two unrelated changes, bleh. In darcs (and git I think) you get to cherry-pick which changes you want to commit right now, and you end up with two commits even though you weren't careful about when you committed. Of course if the changes overlap you're SOL but then it's up to good habits. > 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 :). Do you use those snapshots they added a couple years ago? Or just straight up Undo? > 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 When I was working I aimed for #7. Sometimes it'd be 7.5 - new feature seems to work and nothing I personally use regularly broke either. I would love to move to a point where no one committed to the main repo unless the unit tests pass, and were encouraged not to commit a new feature unless you also add some tests for it. Of course, code talks and I'm just writing emails here :) Cheers, -mike > 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 > -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ------------------------------------------------------------------------------ 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
