I agree (I think). However, just for the sake of consistent behavior, shouldn't we keep the Git detection recursive? (my fix) As I said, that's effectively how SVN detection behaves.
Daniel On Fri, Jul 24, 2009 at 1:34 PM, Assaf Arkin <[email protected]> wrote: > On Fri, Jul 24, 2009 at 11:00 AM, Daniel Spiewak <[email protected] > >wrote: > > > I'm a little confused. Do we need to revert my "fix"? To me, it seems a > > little more natural that the detection would work regardless of location. > > For one thing, just about every Buildr task functions from any project > > directory. For another, the SVN repo detection will work regardless of > > sub-directory (just by virtue of how SVN works). > > > You can buildr release from any directory, since it switches to the root > directory first, then runs the task from there. The issue is: is it a good > idea to run the release cycle (commit, tag, etc) on a sub-tree of your > repository? Like Alexis said, the feature was to not allow that (you > probably want to use git submodule or git subtree). > > Assaf > > > > > > > > > Daniel > > > > On Fri, Jul 24, 2009 at 12:56 PM, Alexis Midon <[email protected] > > >wrote: > > > > > FYI at the time of the 'Git release' implementation, it was a feature > ;) > > > To test whether or not git was the scm, the first impl draft executed a > > git > > > command from the current dir, but we changed it to 'test -d .git' to > make > > > sure the release does not take place in a module of the project, which > > > would > > > be obviously wrong. > > > Antoine's case is different, but I'm afraid your fix won't prevent from > > > releasing from a module. > > > > > > > > > > > > On Fri, Jul 24, 2009 at 7:46 AM, Daniel Spiewak <[email protected]> > > > wrote: > > > > > > > Fixed in r797501. > > > > > > > > For the record, the problem was that we were basing our Git detection > > off > > > > of > > > > whether or not the *current* directory contains .git/config. This > > > > paralleled our detection of SVN (which checks CWD for .svn), but only > > > > worked > > > > if we happened to be cd'd into the root of the Git repository. I > have > > > > adjusted the implementation so that our detection of Git repositories > > is > > > > recursive up to the root. If someone happens to have Windows handy, > it > > > > would be best to make sure this works properly on that platform. > > > > > > > > Daniel > > > > > > > > On Fri, Jul 24, 2009 at 9:25 AM, Daniel Spiewak <[email protected] > > > > > > wrote: > > > > > > > > > This is a trivial little bug. I'm working on fixing it as we > speak. > > > > > > > > > > Daniel > > > > > > > > > > > > > > > On Fri, Jul 24, 2009 at 7:31 AM, Antoine Toulme < > > > [email protected] > > > > >wrote: > > > > > > > > > >> I tried setting a separate project in a git repository, just > because > > > it > > > > >> was > > > > >> less hassle than maintaining two git repositories. > > > > >> The structure is as follows: > > > > >> /.git > > > > >> /Buildfile <-- the main Buildfile > > > > >> /jetty > > > > >> /jetty/Buildfile <-- a secondary Buildfile. The lifecycle of that > > > > project > > > > >> should be very different from the main project, although the main > > > > project > > > > >> depends on it. > > > > >> > > > > >> When trying to do a release, I cd'ed to the jetty directory and > > typed > > > > >> buildr > > > > >> release. Here is the output (with --trace): > > > > >> > > > > >> buildr release --trace > > > > >> (in /Users/antoine/w/cloud-build/jetty, development) > > > > >> ** Invoke jetty (first_time) > > > > >> ** Execute jetty > > > > >> ** Invoke > > > > >> > /Users/antoine/.m2/repository/org/apache/ant/ant/1.7.1/ant-1.7.1.jar > > > > >> (first_time, not_needed) > > > > >> ** Invoke > > > > >> > > > > >> > > > > > > > > > > /Users/antoine/.m2/repository/org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar > > > > >> (first_time, not_needed) > > > > >> ** Invoke > > > > >> > > > > >> > > > > > > > > > > /Users/antoine/.m2/repository/org/apache/ant/ant-trax/1.7.1/ant-trax-1.7.1.jar > > > > >> (first_time, not_needed) > > > > >> ** Invoke /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/java > > > > >> (first_time, not_needed) > > > > >> mkdir -p /Users/antoine/w/cloud-build/jetty/target/tmpdir > > > > >> ** Invoke jetty > > > > >> ** Invoke release (first_time) > > > > >> ** Execute release > > > > >> Buildr aborted! > > > > >> Unable to detect the Version Control System. > > > > >> > > /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/build.rb:433 > > > > >> /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:615:in `call' > > > > >> /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:615:in > `execute' > > > > >> /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in `each' > > > > >> /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:612:in > `execute' > > > > >> > > > > >> > > > > > > > > > > /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:633:in > > > > >> `invoke_with_call_chain' > > > > >> > > > > >> > > > > > > > > > > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/monitor.rb:242:in > > > > >> `synchronize' > > > > >> > > > > >> > > > > > > > > > > /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:619:in > > > > >> `invoke_with_call_chain' > > > > >> > > > > >> > > > > > > > > > > /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:614:in > > > > >> `invoke' > > > > >> /Library/Ruby/Gems/1.8/gems/rake-0.8.4/lib/rake.rb:2027:in > > > `invoke_task' > > > > >> > > > > >> > > > > > > > > > > /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:232:in > > > > >> `top_level' > > > > >> > > > > >> > > > > > > > > > > /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:232:in > > > > >> `each' > > > > >> > > > > >> > > > > > > > > > > /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:232:in > > > > >> `top_level' > > > > >> > > > > >> > > > > > > > > > > /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:499:in > > > > >> `standard_exception_handling' > > > > >> > > > > >> > > > > > > > > > > /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:223:in > > > > >> `top_level' > > > > >> > > > > >> > > > > > > > > > > /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:138:in > > > > >> `run' > > > > >> > > > > >> > > > > > > > > > > /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:499:in > > > > >> `standard_exception_handling' > > > > >> > > > > >> > > > > > > > > > > /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/lib/buildr/core/application.rb:135:in > > > > >> `run' > > > > >> /Library/Ruby/Gems/1.8/gems/buildr-1.3.4/bin/buildr:19 > > > > >> /usr/bin/buildr:19:in `load' > > > > >> /usr/bin/buildr:19 > > > > >> > > > > >> Is there anything I can do about this ? For now I'll use "buildr > > > > upload", > > > > >> it > > > > >> should do just fine. > > > > >> > > > > >> It looks like there is a good possibility that I am abusing the > > system > > > > >> here. > > > > >> > > > > >> Thanks, > > > > >> > > > > >> Antoine > > > > >> > > > > > > > > > > > > > > > > > > > >
