+1 As far as I found out, IntelliJ does not have resource filters, derived flags or anything and is much less structured regarding projects (especially the versions without any module system at all, like webstorm or phpstorm).
For the beginning I would just implement this for git with .gitignore and wait until the need arises for anything else (SVN probably TODO find out conversion). Regards, Holger Holger Schmeisky; holge...@fu-berlin.de Takustraße 9, Room 008, Freie Universität Berlin, 14195 Berlin +49 176 64146306 Am 27.08.2014 19:12, schrieb Graham Allan: > Hi all, > > I've been a long time user of Saros for Eclipse and am currently helping > Holger with feedback for the IntelliJ plugin. I am looking for feedback > on a feature suggestion. > > One issue that we've come across in providing a minimally-usable Saros-I > plugin is which files to exclude from projects. For example, > participants in a session should not share .class files, the .classpath > file, or version control files (e.g. .git, .svn directories). To ignore > files between Eclipse participants, we've used a combination of > "Resource Filters" and marking files/folders as "Derived". These are > both Eclipse-specific features which result in Saros ignoring these > files when negotiating a session, or when edits occur within them. We > initially thought we could achieve the same effect by finding the > equivalent feature in IntelliJ. > > However, that approach has certain downsides: > > - marking files as "Derived" is workspace-specific in Eclipse. Every > participant has to manually mark files as Derived in their own instance > of Eclipse, since the Derived flag can't be shared in a > version-controlled file. This becomes tedious and error prone. > - using "Resource Filters" has the advantage that you can save and > store the definition of filters, since they reside in the .project file. > If you use a build tool that generates the Eclipse config (Maven, > Gradle, sbt) you have to hook into the build process to populate this > file (I have only seen this work in sbt, I can't say how difficult it is > in other build tools). > - there is inconsistency, because some files cannot be managed with > "Resource Filters", mainly, .classpath. > > The best approach we've came across is to use Filtered Resources as much > as possible, and reminding ourselves to mark .classpath as Derived. We > often forget or the Derived flag is lost, which slows down getting a > session started. > > For IntelliJ, I expect we could find the equivalent features, and > manually maintain excluded files outside of Saros. However, I think > there's a better approach, which is to read the "ignore" settings of > local version control, if available. I believe the semantics of ignore > files match the semantics of which files you would want to work together > on with Saros. That is, the overlap between the two definitions is > meaningful, and not a coincidence. > > This approach would have the following benefits: > > - the ignore list for Saros is shared, reducing repeated effort as > participants don't each have their own steps to perform > - there's no incompatibility between a VCS ignore list, and build > tools which generate IDE configuration, so there's no need to hook into > a build tool and maintain that code > - there's no repetition of the files to exclude (many of our rules in > .gitignore are repeated in our Filtered Resources definition) > - it's IDE/editor independent, for example, a hypothetical NetBeans > plugin would share this definition and implementation. > - it makes it consistent when using heterogeneous editors, i.e. > there's less chance an Eclipse-using-participant will have an > incompatible configuration from an IntelliJ-using-participant. > > There's also the following drawbacks: > - there would have to be an implementation within Saros for each > version control system supported, e.g. reading a .gitignore file is very > different from reading SVN's "svn:ignore" property. > - there are issues around the encoding of these files[0]. I don't yet > see why that would be an insurmountable problem. At the worst we could > make a best guess and fail-fast were we could detect inconsistency. The > ignore list could even be negotiated between participants after being > read with different encodings. > > We have personally been happy (enough) to use the tedious, > Eclipse-specific way so far, but I think as Saros becomes available for > more editors, this would be a really nice feature to have. > > > Sorry for the wall of text. What do you think? > > Kind regards, > Graham Allan > > > [0] http://sourceforge.net/p/dpp/bugs/790/ > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > > > > _______________________________________________ > DPP-Devel mailing list > DPP-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dpp-devel > ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel
