[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-users] Multiple users, same workspace

From: Dan Falconer <dan_at_avsupport.com>
Date: 2006-07-27 20:01:36 CEST

On Monday 17 July 2006 1:15 pm, Mark Phippard wrote:
> Dan Falconer <dan@avsupport.com> wrote on 07/17/2006 01:59:11 PM:
> > I'm the head of a development group, and am presently the only one
>
> that uses
>
> > Eclipse/Subclipse: I would like to change this. I wanted to put a copy
>
> of my
>
> > Eclipse directory on the server, and somehow have everybody use that
>
> same
>
> > directory (with their own workspaces) to do development work. Since
>
> it's
>
> > linux, I was planning on just having everybody establish an SSH
>
> connection
>
> > (with X11 forwarding) & forward the GUI.
> >
> > Unfortunately, I've had some problems with Eclipse caching my
>
> username, so
>
> > all the commits go under my name. I'd rather not have each user have
>
> their
>
> > own copy of Eclipse, since my own directory is over 350 megs... any
> > suggestions? I can't imagine I'm the first person that's tried to do
>
> this.
>
> You are probably using JavaSVN for the adapter. It caches Eclipse
> credentials in the keyring and you are probably sharing it, as the default
> location is a common location. You can use the command line argument of
> --keyring to direct the user to a file in their home folder. You might
> also want to do the same for the --configuration argument.
>
> If you are using JavaHL, then it caches information in the Subversion
> runtime configuration folder which defaults to your home folder.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org

        I've tried the given command line arguments. They're not working or I'm not
using them correctly.

SETUP:
        * the development server is called "dev.pl.internal".
        * eclipse, with all the plugins, is stored on dev in /usr/share/eclipse/
        * for simplicity, each user on the dev server has a symlink in their home
directory, pointing to /usr/share/eclipse/

RUNNING IT:
        * normally, to connect & run eclipse, I run:
                ssh -Xf danf@216.239.10.106 "~/eclipse/eclipse"
        * For the command line arguments, I ran this:
                ssh -Xf danf@216.239.10.106 "~/eclipse/eclipse --keyring --configuration"
        * To be safe, I also ran (along with about 3-4 other combinations of
arguments)::
                ssh -Xf danf@216.239.10.106 "~/eclipse/eclipse --keyring=~/_eclipse/.keyring
--configuration=~/_eclipse"

        Every single time, I get an error about the workspace already being in use.
I created a copy of the eclipse directory, and use an rsync dry-run to show
me the files that changed:::

----------------------------[snip]---------------------------
cartman:/usr/share# rsync -av eclipse/ TMP_eclipse/ --dry-run
building file list ... done
./
configuration/.settings/org.eclipse.ui.ide.prefs
configuration/org.eclipse.core.runtime/.manager/
configuration/org.eclipse.osgi/.manager/
---------------------------[/snip]---------------------------

The single file that changed, regardless (apparently) of the command-line args
given to eclipse, was configuration/.settings/org.eclipse.ui.ide.prefs.
I've attached the diff, which clearly shows that the "recent workspaces" gets
transferred between myself (danf) and another developer (taco). Any ideas?

-- 
Best Regards,
Dan Falconer
"Head Geek",
AvSupport, Inc. (http://www.partslogistics.com)


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org

Received on Thu Jul 27 20:02:29 2006

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.