That's why I thought I was abusing the system.I'm not sure it's a good idea
to make a tag of the git repo when releasing a sub-project in it. Would that
be the case right now ?

On Fri, Jul 24, 2009 at 19:56, 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
>> >>
>> >
>> >
>>
>
>

Reply via email to