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

R: R: Subclipse "Checkout as..." (strange?) working

From: Fabio Da Soghe <fabio.dasoghe_at_sysgroup.it>
Date: 2005-08-03 16:56:00 CEST

I've migrated from WTP 0.7 M5 to WTP 0.7 final, and used Checkout as Project, as you suggested. It worked great, so you're right here: if you already have a project in the repository with all .something Eclipse file, you import projects in few seconds and all works fine.

I see a problem when you have to add the Eclipse files to an existing set of source files in the repository: I cannot create a Dynamic Web Module using the "checkout as..." Subclipse command, because Subclipse deletes the just created .something files. I have to do a longer work, creating first a new local project, then importing in some manner the source files from the repository into the project and then sharing the whole project.

Please, don't misunderstand me: I was only searching the right way to do the things we need. Now I know the checkout into an existing non empty directory is tricky, so it's good for me the answer you gave. We'll wait how the subversion checkout process will deal about this issue.

Thanks again for your support.



-----Messaggio originale-----
Da: Mark Phippard [mailto:MarkP@softlanding.com]
Inviato: giovedý 28 luglio 2005 15.04
A: users@subclipse.tigris.org
Oggetto: Re: R: Subclipse "Checkout as..." (strange?) working

Fabio Da Soghe <fabio.dasoghe@sysgroup.it> wrote on 07/28/2005 04:05:00

> Maybe for the Subclipse community this is not a big issue (you don't
> do
> "checkout as..." every day), but my work group has to create quite a
> few
> Eclipse projects sometimes, so for us it's not a trivial problem. And
> I
> it can be a negative introdution to Subclipse for new users, because
it's the
> first command you're likely to use.
> If I'm right (at last!) the problem arises when you put in the
repository the
> .something Eclipse files: in this case if you do a "checkout as..."
> and
> Subclipse don't remove preexisting files, the checkout fails. This takes
> of one Subclipse use case (complete Eclipse project in the
> repository),
> what about other case, when you already have source files (maybe from
> ide) and you want to use them in Eclipse (the case I described in my
first mail)?

I am not sure it is as bad as you think. What you really should be doing
is storing all of these .whatever files in your repository, and then use
the Checkout As Project option. This will then create everything
correctly. The Checkout As ... option exists for a project that does not
have any of the Eclipse files in the repository. Ideally, only one person
would have to do this option, they could then commit the Eclipse files and
then let everyone else use the Checkout As Project option.

I realize there are cases where you will not be allowed to commit those
files, but in those cases it would seem unlikely that the project expects
to have mostly Eclipse-based users. Otherwise, they would allow the

> So, what do you think about having a dialog box in the "checkout as..."
> command which asks the user what to do with Eclipse files? Maybe with a
> explanation for new users (do you already have .something files in the
> repository? Delete files. Do you want to preserve Eclipse's .something
files -
> AND you don't have any of them in the repository? Keep the local files).

That is a possibility I have considered. I would prefer to see the
Subversion checkout process accomodate this, and like I said, this is a
feature that is currently being discussed. If they decide not to do that,
then we should look for alternative ways to handle it.



Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.

To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Thu Aug 4 00:56:00 2005

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.