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 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.
- Create all intermediate directories in SVN to support the
requested module name.
- NOT require entering "trunk" as part of the module name to
share.
- 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.)
- 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.
- Support "replace with" and "compare with" using the standard
SVN repository layout and the "tags" and "branches" dirs.
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).
- Charlie
________________________________
From: Charles Nutter [mailto:cnutter@ventera.com]
Sent: Wednesday, May 04, 2005 9:58 AM
To: users@subclipse.tigris.org
Subject: RE: More on importing large project, layout of
projects/versions/branches in repository
It seems that at least part of the problem was that I was trying to
create a module named "<project>/trunk". When I just allowed Subclipse
to choose the name, it seemed to succeed.
Is this correct behavior? I would like to follow the standard
recommendations for Subversion repository layout (project/trunk,
project/branch, etc) but it seems when adding to the repository it does
not like me specifying this sort of layout.
It also brings another question to mind: Could not Subclipse provide the
very friendly and useful Versions/Branches style tree layout from the
CVS repository view, but behind the scenes be enforcing or supporting
the standard Subversion repository layout?
One of the biggest problems I've had with Subversion is that it's almost
too permissive in how projects/versions/branches are laid out in the
repository...permissive to the point of confusion, since I have seen
multiple conflicting recommendations at various times. It would be great
if Subclipse could have a "strict" mode of operation that takes care of
generating and maintaining this layout for me.
- Charlie
________________________________
From: Charles Nutter [mailto:cnutter@ventera.com]
Sent: Wednesday, May 04, 2005 1:29 AM
To: users@subclipse.tigris.org
Subject: More on importing large project
I tried again today to import a large project. I added it to source
control, went to the sync view, chose Commit at the root of the sync
tree, entered my comment, hit Select All to add all listed files to
version control, and proceeded from there. I got this message:
The SVN synchronization information for {0} has become corrupt or does
not exist.
I'm running current Subclipse and JavaSVN. The server should be running
Subversion 1.1-ish.
I thought I saw this mentioned somewhere before, but could not find the
reference...
--
Charles Oliver Nutter | Senior Specialist, Architect
Ventera Corporation | Minneapolis, Minnesota
Office: 612-370-3061 | Mobile: 612-710-1274
Received on Tue May 10 01:08:42 2005