In a single SVN repository, it is possible to host more than one project within the same tree.
For example: project1 trunk tags branches project2 trunk tags branches Someone triggering buildr release in project1/trunk would want a tag of his trunk folder go under project1/tags. git obviously isn't the same game. I suppose you should change the error message, so that rather than saying there is no git repository here, say that with git a release tags the whole repository and that the buildfile should be at its root. Cheers, Antoine On Fri, Jul 24, 2009 at 20:52, Assaf Arkin <[email protected]> wrote: > 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 > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
