Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [subversive-dev] How does subversive stop .svn folders from being copied by the Java Builder?

Hello Kris,

Firstly - thank you for pointing the issue. And there is a question: is the only time the problem happens is on the initial import of a shared project into a workspace? If so, then it definitely is the problem. If it happens on other conditions too then there could be another issue I should search for.

Best regards,
Alexander Gurov.

22.10.2011 3:35, Kris De Volder пишет:
Hmmm... it is starting to look more and more like a subversive bug to me. But I will leave the final judgment of that to you guys (i.e. subversive devs).

Here's what I learned:

1) org.eclipse.team.svn.core.SVNFolderListener is the guy who makes .svn folders team private.

2) this is installed as a workspace change listener by
    org.eclipse.team.svn.core.SVNTeamPlugin
    at line 169.

    Here it registers to receive 'PRE_BUILD' events. I gather this is with intention to make sure those
    .svn folders are indeed made 'team private' before the Java builder executes.

    So that seems cool.

3)  But... it seems that the SVNFolderListener *schedules* the work to be done rather than actually doing the work.

     This happens at line: 115 in SVNFolderListener.

     The end result is that the work *actually* only happens after the JavaBuilder already copied the .svn folders
     to the output folder. This is too late, because the damage is already done.

4) Finally,

    The SVNFolderListener is then causing all the copied .svn folders inside the project's output folders to
    also be marked 'team private'. Not sure what the effect of that might be, but I think it is almost certainly bad,
    and could be the reason why the Java builder is not removing them from the output folders on successive builds.

Any thoughts?

Kris

----- Original Message -----
OK, I think I made some headway, at least in figuring out how its
supposed to
be done.

Found this info:

http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fteam.htm

I recon that must be the mechanism subversive team provider is using
to mark .svn
folders as 'do not copy' for the Java builder.

If that's the case, now all I need to figure out is why subversive
isn't doing this *before* the Java builder already copied some of
the .svn folders to the output folder.

Kris

----- Original Message -----
Hi all,

Hopefully this is the right place for my question, because I've
been
banging my head against a problem which may be a subversive bug, or
it may (more likely :-) be something stupid that I myself did in an
import wizard I implemented for the Gradle STS tooling.

See here for some background:

https://issuetracker.springsource.com/browse/STS-2173

Trying to get to the bottom of this yesterday, I spent quite a bit
of
time not really getting anywhere.

What I need to know to make some headway debugging this, is how
does
subversive stop the Java builder from copying .svn folders into the
output folder? I know there's some mechanism in place that does
this, and normally it does work, just in the bug reported above, it
sometimes doesn't and I can't figure out why not. I'm somewhat
hampered by the fact that I don't know where to look for this
mechanism.

If someone could point me to the right place in the subversive code
base that implements this filtering mechanism I can spend some more
time with the debugger to try to get to the bottom of it.

Any help much appreciated.

Cheers,

Kris
_______________________________________________
subversive-dev mailing list
subversive-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/subversive-dev

_______________________________________________
subversive-dev mailing list
subversive-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/subversive-dev

_______________________________________________
subversive-dev mailing list
subversive-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/subversive-dev



Back to the top