Hi Ian, 2013/6/2 Ian Boston <i...@tfd.co.uk>
> > > If by "true dev" you mean IDE only, then I will find that too restrictive, > others may too. I use whatever is most efficient to get the job done, > sometimes thats the IDE (refactoring), sometimes its the command line > (branch management, full scale rebuilds). To say to use Sling tooling you > can only use the IDE will be too restrictive. > > right, I totally agree. And usually I use the most efficient tool available for the job as well - however, I believe that most jobs where today I have to leave the IDE can be done as efficient (and even more efficient) through the IDE with the right tooling. > However the question you raise is not should developers be allowed to use > command line, its should changes in a Sling repo be automatically reflected > on the filesystem ? (I agree auto syncing between Sling and the internal > IDE state without reference to the file system is not useful). > > Yepp. > I have found Sling -> FS auto syncing useful for several reasons. > 1. The IDE lets me know if files in the repo are being changed, with the > message, '....do you want to reload this file.' > 2. When I do a svn status, or git status I know I am looking at an exact > copy of what I just tested. > 3. Because of 1 and 2 I can be certain that what I am editing is what I am > testing and the repo: > a) Hasn't mysteriously branched. > b) Hasn't overwritten the change I just made with one of its own. (try one > way sync to experience this, its very frustrating until you work out whats > happening) > 4. I can load things into the repo and have them appear in the IDE. > > But I dont want to steer this thread if the intention was for tooling that > would only work if everything is done in the IDE. > > I think you're bringing up very good points - and I totally agree to address them in one way or the other. But :) we should really think before we implement the "we need everything in all possible combinations" solution (I'm exaggerating here of course to make a point). For example in the above scenario, it's pretty easy to accidentally change content in the repo which then overwrites your project checkout without noticing it, especially if you haven't opened your IDE in that time. Which in turn would require to check all changes in your project checkout before committing it back. Doable, but I've seen many problems in this area where people blindly commit their project changes without thinking about why they are in their project. Sure, we can't prevent every potential human error - but I would like to define a workflow which covers mostly everything from working within the IDE. This would also be inline with efforts in the OSGi world where you would be able to do everything within your IDE. And of course, things like Maven would still be used for automated building etc. Carsten -- Carsten Ziegeler cziege...@apache.org
