"Charles Nutter" <cnutter@ventera.com> wrote on 05/09/2005 11:08:42 AM:
> I tried creating the base folder for a project in SVN via Subclipse
first
> today, but it still fails when trying to share something as
“project/trunk”
> with the error in my original email. It seems there is no way to import
a
> project into the standard Subversion directory structure using
> Subclipse/JavaSVN currently…am I wrong?
I do it pretty regularly. You have to create the "project" folder
manually in the Repo browser. Then, when sharing you say "Use specified
module name" and enter "Project/trunk". It is important that trunk not
exist already.
> I believe Subclipse should be able to do the following:
>
> - Import initial projects into “project/trunk”. Do this all the
time,
> but make it transparent and non-confusing in the repository view.
This works, see above. Any UI could be easier, but it is not obvious to
me what realistic improvements could be made.
> - Create all intermediate directories in SVN to support the
requested
> module name.
I think Subversion should do this. When it supports it, I will certainly
add that in to Subclipse. I think that will also make the process easier
since you will not need to know you had to manually create the "Project"
folder.
> - NOT require entering “trunk” as part of the module name to
share.
I don't agree. I do not want to be in the business of forcing a way of
using the tool on people. I think there are a lot of people that do not
follow the "recommendations" to the letter. The Subversion devs would be
loathe to call it a "recommendation". Just something that works well in
some situations.
> - Show “trunk”, tags, and branches as “checkout-able” in
repository
> view, as CVS does with projects under HEAD and individual tagged and
branched
> projects. (I understand SVN supports more advanced nested structures for
> repositories…but Eclipse *does not* and so it makes sense to limit and
> structure Subclipse behavior as the CVS module does.)
It shows you your entire repository. It can checkout anything. I do not
agree it should be different.
> - Support creating branches and tags as simply as the CVS
module, by
> putting them under “project/tags” or “project/branches” automatically,
> creating ancestor directories in SVN if necessary.
I think it already is very simple.
> - Support “replace with” and “compare with” using the standard
SVN
> repository layout and the “tags” and “branches” dirs.
This one I agree with. This needs to be added in some fashion.
> I think this would be a minimum set of requirements for any team to
whole-
> heartedly swap out CVS for SVN in an Eclipse-heavy environment. Managing
a SVN
> repository that doesn’t follow recommended practices would be awful, but
> trying to manually assemble it BEFORE importing, tagging, or branching
code is
> even worse. Without clean, transparent support for the de-facto SVN
standards,
> people will actually be encouraged not to follow those standards.
>
> It’s great that Subversion is so flexible, and I’m sure that flexibility
> enables all sorts of new and creative applications of version control,
but I
> think that flexibility is detrimental to typical *project* version
control. A
> certain subset of functionality, structure, and behavior is necessary to
keep
> a repository manageable, e.g. the recommended Subversion repository
layout and
> usage patterns. The Eclipse team chose to support only the most standard
> functions and behaviors in the core CVS module…I believe Subclipse
should do
> the same (and perhaps add more advanced, flexible operations later).
I think this goes beyond flexibility. These are integral features of
Subversion. We cannot simply not support them.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Tue May 10 02:24:51 2005