On Fri, Jul 24, 2009 at 11:42 AM, Daniel Spiewak <[email protected]>wrote:
> 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. Or we could fix SVN detection to be consistent. The buildfile is supposed to reside at the root of your project, which is where you would find the .git file, so I would say the Git behavior is correct but SVN is broken. Assaf > > > 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 > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >
