Spring Tool Suite
  1. Spring Tool Suite
  2. STS-2173

Importing a Gradle project under version control: timing/building issue

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.8.0.M2
    • Fix Version/s: 2.9.0.M1
    • Component/s: GRADLE
    • Labels:
      None

      Description

      Suppose you have a Gradle multiproject under version control (Subversion, for instance).
      You check it out in a folder, say d:\myprj.
      Let's say the Eclipse workspace is in d:\workspace and it is empty.
      In Eclipse you do an import using the Gradle project import wizard; you select the d:\myprj folder, you presso the "build model" and then select the whole myprj multiproject, including its subprojects, and import it.

      Then, the Gradle import wizard starts to create the projects in the workspace, set dependencies, etc.
      What I'm observing is that if the myprj is huge, it takes some time before:

      • all the projects are created in the workspace
      • dependencies are set
      • the SVN data is collected so that projects are recognized as under version control (the repository decoration appears on project and file icons in Project/Package Explorer)
      • the project is built

      The problem I observe is this. Having "build automatically" enabled, the project building can start BEFORE the SVN data is collected. This means that there's a timeframe in which the building of the project is made before the IDE realizes that the project is under version control.

      What does this mean? It means that the "copying resources to the output folder" operations DOES NOT apply the exclusion filters inherited by the SCM plugin: in my case I find that the "bin" output folder of my projects contain copies of the .svn folders coming from the source folders.

      This can lead to severe problems, especially if you don't use the resource filters to hide subprojects in the main project and you make a synchronization with the repository.

      It's not easy to revert from this situation. If you clean all the projects after they have been recognized as being under version control, the "bin" output folders are cleaned, but the .svn folders right inside them are not removed. I mean, if after the first build the situation is this:

      • mysubprj
      • bin
      • .svn
      • com
      • .svn
      • example
      • .svn
      • package
        (etc.)

      after cleaning the situation becomes this:

      • mysubprj
      • bin
      • .svn
      • com
      • example
      • package
        (etc.)

      So, the .svn folders inside the packages are removed, but the one directly inside bin is not.

      You have to manually remove that folder to take things back to normal.

      My idea is the following: isn't there a way to "force" the team plugin (i.e.: Subversive, CVS, etc.) to collect the needed data BEFORE letting the first build of the imported project(s) start? I don't know if it's just a problem of setting the SVN nature before the Java nature or something like that (I'm not so expert...).

        Activity

        Hide
        Mauro Molinari added a comment -

        Sorry, JIRA editor flattened the raw directory structure I meant to draw. I hope the explanation is clear anyway.

        Show
        Mauro Molinari added a comment - Sorry, JIRA editor flattened the raw directory structure I meant to draw. I hope the explanation is clear anyway.
        Hide
        Kris De Volder (c) added a comment -

        This is tricky... I don't actually know how your projects are getting the SVN nature, I must assume those natures are already present in the existing config (.project) files.

        Unfortunately I don't really know a mechanism that could allow me to force the build to be delayed to after the SVN plugin does its thing. The truth is that both of these are more or less independent things that Eclipse is in charge of scheduling. The gradle tooling doesn't control their order or scheduling rules.

        Do problems like this also happen if you import projects like yours using a standard eclipse import wizard (e.g. with "File >> Import >> existing projects into workspace")?

        Show
        Kris De Volder (c) added a comment - This is tricky... I don't actually know how your projects are getting the SVN nature, I must assume those natures are already present in the existing config (.project) files. Unfortunately I don't really know a mechanism that could allow me to force the build to be delayed to after the SVN plugin does its thing. The truth is that both of these are more or less independent things that Eclipse is in charge of scheduling. The gradle tooling doesn't control their order or scheduling rules. Do problems like this also happen if you import projects like yours using a standard eclipse import wizard (e.g. with "File >> Import >> existing projects into workspace")?
        Hide
        Kris De Volder (c) added a comment -

        One possibility to consider could be to have the wizard disable the 'Build automatically' option in the workspace and only re-enable it at some 'safe time'. Just need some idea on determining when it is 'safe'.

        I guess this determination of 'safe time' could vary depending on the project natures applied to the imported projects.

        Show
        Kris De Volder (c) added a comment - One possibility to consider could be to have the wizard disable the 'Build automatically' option in the workspace and only re-enable it at some 'safe time'. Just need some idea on determining when it is 'safe'. I guess this determination of 'safe time' could vary depending on the project natures applied to the imported projects.
        Hide
        Mauro Molinari added a comment -

        I agree with your thoughts. Manually disabling the "Build automatically" before importing is the only work around I could think of at the moment.

        Honestly, I never saw such a problem with "File >> Import >> existing projects into workspace", but consider that:
        1. I've always used that function only with projects shared with CVS, rather than SVN
        2. I've always used that function with simple "plain" projects (maximum 3 at a time), while my testings now are against an import of a Gradle multiproject made up of 22 subprojects + the main project; so, the work needed to import such a huge number of projects, with STS/Gradle working in the background to set up project dependencies and all the other things, may slow down the process of Subversive to do its initialization.

        I really don't know where the SVN nature is stored. In the .project files I don't find any reference to Subversive (or even Subversion generically). To be honest, I could never understand where Eclipse saves the fact that a project uses Subversive or, say, Subclipse (which is another plugin for accessing Subversion from Eclipse)... In fact, you can't simply uninstall one and install the other to see your project working out of the box with SVN... but you have to do a complex mechanism to "disconnect" a project, uninstall one plugin, then install the other and finally share your project with the new plugin to make things work. So, maybe a deeper understanding of this aspect may help here?

        Show
        Mauro Molinari added a comment - I agree with your thoughts. Manually disabling the "Build automatically" before importing is the only work around I could think of at the moment. Honestly, I never saw such a problem with "File >> Import >> existing projects into workspace", but consider that: 1. I've always used that function only with projects shared with CVS, rather than SVN 2. I've always used that function with simple "plain" projects (maximum 3 at a time), while my testings now are against an import of a Gradle multiproject made up of 22 subprojects + the main project; so, the work needed to import such a huge number of projects, with STS/Gradle working in the background to set up project dependencies and all the other things, may slow down the process of Subversive to do its initialization. I really don't know where the SVN nature is stored. In the .project files I don't find any reference to Subversive (or even Subversion generically). To be honest, I could never understand where Eclipse saves the fact that a project uses Subversive or, say, Subclipse (which is another plugin for accessing Subversion from Eclipse)... In fact, you can't simply uninstall one and install the other to see your project working out of the box with SVN... but you have to do a complex mechanism to "disconnect" a project, uninstall one plugin, then install the other and finally share your project with the new plugin to make things work. So, maybe a deeper understanding of this aspect may help here?
        Hide
        Kris De Volder (c) added a comment -

        I really don't know where the SVN nature is stored. In the .project files

        {/quote}

        No problem. I just meant to say that it isn't an aspect of the project that's handled by the wizard (at least not at the moment). It's really some other plugin that added those config bits and in some sense its that other plugins responsibility to make sure it does its job right.

        Nevertheless, our wizard may be in a position to do something to avoid messes created by having builds being run too early.

        Is this project you are talking about (with its 22 subprojects available as open source somewhere. If so I could try and import it and play with it a bit to see if I can make things more smooth by tweaking some scheduling rules and/or disabling auto-build etc.

        Show
        Kris De Volder (c) added a comment - I really don't know where the SVN nature is stored. In the .project files {/quote} No problem. I just meant to say that it isn't an aspect of the project that's handled by the wizard (at least not at the moment). It's really some other plugin that added those config bits and in some sense its that other plugins responsibility to make sure it does its job right. Nevertheless, our wizard may be in a position to do something to avoid messes created by having builds being run too early. Is this project you are talking about (with its 22 subprojects available as open source somewhere. If so I could try and import it and play with it a bit to see if I can make things more smooth by tweaking some scheduling rules and/or disabling auto-build etc.
        Hide
        Mauro Molinari added a comment -

        Unfortunately, it is not open source...

        I'll try to reproduce with a smaller test project. If I succeed, I'll attach it here.

        Show
        Mauro Molinari added a comment - Unfortunately, it is not open source... I'll try to reproduce with a smaller test project. If I succeed, I'll attach it here.
        Hide
        Mauro Molinari added a comment -

        I prepared a Gradle multiproject that shows the problem in my system almost always.

        It contains some open-source code of the JBossTS JTA project. It is provided here just to test. It also includes some JARs of other JBoss open source projects. Please consider deleting the file if this is not the best way to distribute this software: I repeat, I included it here just for debug/test purposes.

        Then, do the following:

        • download the project zip file
        • unpack the zip file into a folder
        • check the contents into a Subversion repository, for instance at: svn://host/repo/prj/trunk
        • checkout the same project into a folder of you system, so that you now have a working copy under version control
        • start Eclipse
        • ensure you have the following plugin installed: Subversive (www.eclipse.org/subversive) with the SVNKit connector (I don't know if using one connector or the other makes any difference)
        • ensure Eclipse isn't doing anything (building other projects, for instance)
        • open the STS Gradle Import Wizard
        • select the folder containing the working copy of the project
        • hit Build Model
        • ensure the following options:
          run before = checked
          run after = checked
          create resource filters = unchecked
          use hierarchical project names = checked
          add to working set 'project name' = checked
        • select the multiproject (and all the subprojects) and hit Finish

        STS will import all the projects. What I see is that:

        • projects appear in the workspace gradually
        • the decorations that identify the type of projects appear gradually (ex.: the Java project decorator, the Gradle project decorator, the shared project decorator, etc.); in particular, the "silos" icon representing the fact that the projects are under version control appear after a while
        • meanwhile, the building of the four projects has started; if it has started before the import of all the four projects have finished, temporary build problems icon decorators may appear on the project icons; they disappear as soon as the import has finished

        Wait for the whole process to finish: then, look at the project folders on the file system, especially the bin folder created besides src. In there you'll find the .svn folder! You may also find it inside the packages folders! These .svn folders shouldn't be there: they have been copied while "copying resources to the output folder". They are not hidden (while the "real" .svn folder have the hidden attribute under Windows) and if you look at the metadata files in there, you'll see that they're referencing files that are actually in the src folders.

        Do some tests with "Project | Clean..." and you'll observe what I've written in the description.

        I hope you succeed at reproducing the problem.

        Show
        Mauro Molinari added a comment - I prepared a Gradle multiproject that shows the problem in my system almost always. It contains some open-source code of the JBossTS JTA project. It is provided here just to test. It also includes some JARs of other JBoss open source projects. Please consider deleting the file if this is not the best way to distribute this software: I repeat, I included it here just for debug/test purposes. Then, do the following: download the project zip file unpack the zip file into a folder check the contents into a Subversion repository, for instance at: svn://host/repo/prj/trunk checkout the same project into a folder of you system, so that you now have a working copy under version control start Eclipse ensure you have the following plugin installed: Subversive (www.eclipse.org/subversive) with the SVNKit connector (I don't know if using one connector or the other makes any difference) ensure Eclipse isn't doing anything (building other projects, for instance) open the STS Gradle Import Wizard select the folder containing the working copy of the project hit Build Model ensure the following options: run before = checked run after = checked create resource filters = unchecked use hierarchical project names = checked add to working set 'project name' = checked select the multiproject (and all the subprojects) and hit Finish STS will import all the projects. What I see is that: projects appear in the workspace gradually the decorations that identify the type of projects appear gradually (ex.: the Java project decorator, the Gradle project decorator, the shared project decorator, etc.); in particular, the "silos" icon representing the fact that the projects are under version control appear after a while meanwhile, the building of the four projects has started; if it has started before the import of all the four projects have finished, temporary build problems icon decorators may appear on the project icons; they disappear as soon as the import has finished Wait for the whole process to finish: then, look at the project folders on the file system, especially the bin folder created besides src. In there you'll find the .svn folder! You may also find it inside the packages folders! These .svn folders shouldn't be there: they have been copied while "copying resources to the output folder". They are not hidden (while the "real" .svn folder have the hidden attribute under Windows) and if you look at the metadata files in there, you'll see that they're referencing files that are actually in the src folders. Do some tests with "Project | Clean..." and you'll observe what I've written in the description. I hope you succeed at reproducing the problem.
        Hide
        Kris De Volder (c) added a comment -

        Thanks for that, I'll have a look and report back later.

        Show
        Kris De Volder (c) added a comment - Thanks for that, I'll have a look and report back later.
        Hide
        Kris De Volder (c) added a comment -

        I tried to import the project, but as far as I can tell it doesn't have any SVN related stuff in it.
        I also had some trouble importing the projects because the model builds are failing because of missing dependencies.

        Note by the way that the decorations appearing gradually isn't really allarming. Eclipse typically does this kind of decoration in low priority threads/jobs to make the UI more responsive.

        The .svn dirs ending up in the bin folder seems like something more serious however. But I haven't been able to reproduce with this sample project.

        I really appreciate you taking the time and making the effort to put this test project together, but I wonder if perhaps you didn't quite package up everything correctly/completely.

        Show
        Kris De Volder (c) added a comment - I tried to import the project, but as far as I can tell it doesn't have any SVN related stuff in it. I also had some trouble importing the projects because the model builds are failing because of missing dependencies. Note by the way that the decorations appearing gradually isn't really allarming. Eclipse typically does this kind of decoration in low priority threads/jobs to make the UI more responsive. The .svn dirs ending up in the bin folder seems like something more serious however. But I haven't been able to reproduce with this sample project. I really appreciate you taking the time and making the effort to put this test project together, but I wonder if perhaps you didn't quite package up everything correctly/completely.
        Hide
        Mauro Molinari added a comment -

        Hi Kris,
        to get the .svn folders you should have to follow steps 3. and 4. of my previous comment.
        That is, once downloaded the ZIP file, you should check it in a Subversion repository, and then checkout on another folder to get a working copy (=> that is, a copy under version control, with the .svn folders in it).
        I can't send you my project with .svn folders, because it points to a host in our LAN and it would mess your Subversive plugin up, so I think you couldn't reproduce the problem correctly.
        I hope you have a Subversion repository to test with...

        Regarding the missing dependencies... what is missing actually? It should contain a main project, three subprojects (A, B and C) and 4 JARs in the "repo" dir (hornetq-core.jar, ironjacamar-spec-api.jar, jboss-logging.jar, jboss-transaction-api_1.1_spec.jar), which are declared as dependencies in the main project build.gradle like this:

        build.gradle
        subprojects {subprj->
        	
        		apply plugin: 'java'
        		apply plugin: 'eclipse'
        		
        		repositories {
        			flatDir dirs: "${rootProject.projectDir}/repo"
        		}
        		
        		dependencies {
        			compile ':jboss-logging:@jar'
        			compile ':jboss-transaction-api_1.1_spec:@jar'
        			compile ':ironjacamar-spec-api:@jar'
        			compile ':hornetq-core:@jar'
        		}
        		
        		sourceCompatibility = '1.6'
        		targetCompatibility = '1.6'
        	
        		compileJava {  options.encoding = 'ISO-8859-1' }
        	}
        }
        

        I'm using STS Gradle Integration 2.8.0.201109212341-M2, with Gradle version at http://repo.gradle.org/gradle/distributions-snapshots/gradle-1.0-milestone-5-20110927091445+0200-bin.zip

        Show
        Mauro Molinari added a comment - Hi Kris, to get the .svn folders you should have to follow steps 3. and 4. of my previous comment. That is, once downloaded the ZIP file, you should check it in a Subversion repository, and then checkout on another folder to get a working copy (=> that is, a copy under version control, with the .svn folders in it). I can't send you my project with .svn folders, because it points to a host in our LAN and it would mess your Subversive plugin up, so I think you couldn't reproduce the problem correctly. I hope you have a Subversion repository to test with... Regarding the missing dependencies... what is missing actually? It should contain a main project, three subprojects (A, B and C) and 4 JARs in the "repo" dir (hornetq-core.jar, ironjacamar-spec-api.jar, jboss-logging.jar, jboss-transaction-api_1.1_spec.jar), which are declared as dependencies in the main project build.gradle like this: build.gradle subprojects {subprj-> apply plugin: 'java' apply plugin: 'eclipse' repositories { flatDir dirs: "${rootProject.projectDir}/repo" } dependencies { compile ':jboss-logging:@jar' compile ':jboss-transaction-api_1.1_spec:@jar' compile ':ironjacamar-spec-api:@jar' compile ':hornetq-core:@jar' } sourceCompatibility = '1.6' targetCompatibility = '1.6' compileJava { options.encoding = 'ISO-8859-1' } } } I'm using STS Gradle Integration 2.8.0.201109212341-M2, with Gradle version at http://repo.gradle.org/gradle/distributions-snapshots/gradle-1.0-milestone-5-20110927091445+0200-bin.zip
        Hide
        Mauro Molinari added a comment -

        Hi Kris, I just tried to unzip the attached zip and to "build model" on it and it works. Maybe it's just a problem of the Gradle version you use?

        Show
        Mauro Molinari added a comment - Hi Kris, I just tried to unzip the attached zip and to "build model" on it and it works. Maybe it's just a problem of the Gradle version you use?
        Hide
        Kris De Volder (c) added a comment -

        Could be, what Gradle version should I be using with this project? (I.e what version are you using with it).

        Sorry I missed the bit about checking stuff into SVN. I should read the instructions more carefully. I'll give it another try.

        Show
        Kris De Volder (c) added a comment - Could be, what Gradle version should I be using with this project? (I.e what version are you using with it). Sorry I missed the bit about checking stuff into SVN. I should read the instructions more carefully. I'll give it another try.
        Hide
        Kris De Volder (c) added a comment -

        OK, I was able to reproduce the behavior you describe... and yes the .svn folders end up in the bin folder of the subporjects.
        This is odd, confusing and certainly creates problems.

        I'm not quite sure yet who's problem this really is to solve (ours or subversive's, or the Java builder).

        It doesn't seem to happen to the root project, only subprojects.

        BTW: the missing dependencies was because of this bug: http://issues.gradle.org/browse/GRADLE-1621
        This went away after making sure to use tooling-api jars that are latest M5 snapshot.

        Show
        Kris De Volder (c) added a comment - OK, I was able to reproduce the behavior you describe... and yes the .svn folders end up in the bin folder of the subporjects. This is odd, confusing and certainly creates problems. I'm not quite sure yet who's problem this really is to solve (ours or subversive's, or the Java builder). It doesn't seem to happen to the root project, only subprojects. BTW: the missing dependencies was because of this bug: http://issues.gradle.org/browse/GRADLE-1621 This went away after making sure to use tooling-api jars that are latest M5 snapshot.
        Hide
        Mauro Molinari added a comment - - edited

        I think it's just a "timing problem": if the necessary Subversive initialization things were "fast enough" to be completed before the first project build starts, there wouldn't be any problem. This is because I'm almost certain that when the plugin is operating, it automatically adds some exclusion filters to the resources that need to be copied in the output folder.

        So, I don't really know what's the right thing to do... Maybe there's a way to temporarily flag projects to disable their building (even though "build projects automatically" is checked)... If so, it would be just a matter of knowing when the share Team API (for Subversive, in this case, but I would not be surprised if the same problem arises with CVS, Subclipse or other) has finished its work, before letting the project building process do its job again...

        Would it be useful to ask the Eclipse developers for help?

        Show
        Mauro Molinari added a comment - - edited I think it's just a "timing problem": if the necessary Subversive initialization things were "fast enough" to be completed before the first project build starts, there wouldn't be any problem. This is because I'm almost certain that when the plugin is operating, it automatically adds some exclusion filters to the resources that need to be copied in the output folder. So, I don't really know what's the right thing to do... Maybe there's a way to temporarily flag projects to disable their building (even though "build projects automatically" is checked)... If so, it would be just a matter of knowing when the share Team API (for Subversive, in this case, but I would not be surprised if the same problem arises with CVS, Subclipse or other) has finished its work, before letting the project building process do its job again... Would it be useful to ask the Eclipse developers for help?
        Hide
        Kris De Volder (c) added a comment -

        I spent a lot of time yesterday trying to figure out how Subversive is making those 'exclusions filters'. Try as a I might, I couldn't find where and how it is actually doing that.

        It isn't via the java builder preference, nor is it via project level resource filters. So I don't know how it works and what triggers it. So I also don't know why it isn't happening fast enough. In all this I am still not able to say whether this is a problem with my import wizard or with subversion plugin.

        I do know that I've not been able to reproduce the problem using the 'plain' Eclipse import wizard so far, so it does suggest it may be because of something that I'm doing or not doing.

        It is likely a timing problem, as you say. But I don't want to jump to that conclusion unless I really see with my own eyes somehow how the sequence of events plays out.

        I did find some 'fix' yesterday. If I add exclusions to the source folders for "*/.svn/" and "/.svn//" then this stops the inadvertent copying.

        I don't really like this 'solution' and didn't commit it however, since clearly there is a mechanism already in place, which for some reason isn't working.

        Yes, trying to get some info out of the subversive devs may be useful... I'll have to go find the right mailing list

        Show
        Kris De Volder (c) added a comment - I spent a lot of time yesterday trying to figure out how Subversive is making those 'exclusions filters'. Try as a I might, I couldn't find where and how it is actually doing that. It isn't via the java builder preference, nor is it via project level resource filters. So I don't know how it works and what triggers it. So I also don't know why it isn't happening fast enough. In all this I am still not able to say whether this is a problem with my import wizard or with subversion plugin. I do know that I've not been able to reproduce the problem using the 'plain' Eclipse import wizard so far, so it does suggest it may be because of something that I'm doing or not doing. It is likely a timing problem, as you say. But I don't want to jump to that conclusion unless I really see with my own eyes somehow how the sequence of events plays out. I did find some 'fix' yesterday. If I add exclusions to the source folders for "* /.svn/" and " /.svn/ / " then this stops the inadvertent copying. I don't really like this 'solution' and didn't commit it however, since clearly there is a mechanism already in place, which for some reason isn't working. Yes, trying to get some info out of the subversive devs may be useful... I'll have to go find the right mailing list
        Hide
        Davide Cavestro added a comment -

        hi Kris, just a memo...
        I've seen Kris tried at http://dev.eclipse.org/mhonarc/lists/subversive-dev/msg00207.html
        In case they don't reply in a reasonable time, you could also try the community forum for subversive at http://www.eclipse.org/forums/index.php/f/73/

        Cheers
        Davide

        Show
        Davide Cavestro added a comment - hi Kris, just a memo... I've seen Kris tried at http://dev.eclipse.org/mhonarc/lists/subversive-dev/msg00207.html In case they don't reply in a reasonable time, you could also try the community forum for subversive at http://www.eclipse.org/forums/index.php/f/73/ Cheers Davide
        Hide
        Mauro Molinari added a comment -

        Manually adding the exclusion for .svn folders has the problem that, if it's STS fault (and we're not sure it is) this would solve just the case for Subversion integration, but not with other SCM plugins.

        I didn't try the same scenario with CVS sharing, I may do some tests to see if the same happens...

        Mauro.

        Show
        Mauro Molinari added a comment - Manually adding the exclusion for .svn folders has the problem that, if it's STS fault (and we're not sure it is) this would solve just the case for Subversion integration, but not with other SCM plugins. I didn't try the same scenario with CVS sharing, I may do some tests to see if the same happens... Mauro.
        Hide
        Kris De Volder (c) added a comment -

        I think we are hitting a subversive bug here:
        https://bugs.eclipse.org/bugs/show_bug.cgi?id=361831

        Yes, it would be nice to test CVS, git, and even other SVN support, like subclipse. They could have problems also, but they wouldn't be (or shouldn't be considered) the same bug.

        Show
        Kris De Volder (c) added a comment - I think we are hitting a subversive bug here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=361831 Yes, it would be nice to test CVS, git, and even other SVN support, like subclipse. They could have problems also, but they wouldn't be (or shouldn't be considered) the same bug.
        Hide
        Mauro Molinari added a comment -

        Thank you Kris, I'm following your discussion with Alexander Gurov and the opened bug.

        I may try Subclipse to see if it suffers of the same problem.

        Meanwhile, for me it's ok to close this bug as it isn't STS's fault. Feel free to do as you like.

        Show
        Mauro Molinari added a comment - Thank you Kris, I'm following your discussion with Alexander Gurov and the opened bug. I may try Subclipse to see if it suffers of the same problem. Meanwhile, for me it's ok to close this bug as it isn't STS's fault. Feel free to do as you like.
        Hide
        Kris De Volder (c) added a comment - - edited

        Since I think it may be hard for the subversive devs to reproduce. I created a small patch that fixes the bug for me.

        https://bugs.eclipse.org/bugs/attachment.cgi?id=205870&action=diff

        I'll close this bug as 'won't fix'. It isn't something we can fix in STS, but I'll follow up with the Eclipse bug to get my patch applied.

        Show
        Kris De Volder (c) added a comment - - edited Since I think it may be hard for the subversive devs to reproduce. I created a small patch that fixes the bug for me. https://bugs.eclipse.org/bugs/attachment.cgi?id=205870&action=diff I'll close this bug as 'won't fix'. It isn't something we can fix in STS, but I'll follow up with the Eclipse bug to get my patch applied.
        Hide
        Mauro Molinari added a comment -

        Hi Kris,
        I just verified that Subclipse does not suffer from this problem.
        It's hard for me to test with CVS now, while I don't know Git at all and its decentralized nature makes me think that things may be quite different.

        So, I think it was just a Subversive issue. Thanks for finding it out and help the Subversive team to fix it.

        Show
        Mauro Molinari added a comment - Hi Kris, I just verified that Subclipse does not suffer from this problem. It's hard for me to test with CVS now, while I don't know Git at all and its decentralized nature makes me think that things may be quite different. So, I think it was just a Subversive issue. Thanks for finding it out and help the Subversive team to fix it.

          People

          • Assignee:
            Kris De Volder (c)
            Reporter:
            Mauro Molinari
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: