You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Brandon Ehle <az...@yahoo.com> on 2004/04/07 06:21:09 UTC
Summarizing the gigantic "Dropping Subversion" thread
After reading through the whole "Dropping Subversion" thread, it seems
to boil down into a couple issues.
1) There are some paradigms in Subversion that do not map one to one
with paradigms in source control X.
2) Subversion has some flexibility that does not exist in source control
Y, and because we have not had this in the past, we do not know how to
take advantage of this flexibility
3) It takes more effort to do operation FOO in Subversion than in source
control Z.
All of this is to be expected with a new version control system. No
matter which system you are coming from, there are some changes that
you'll have to make to your work pattern to be most effective with
Subversion (and as with any new tool).
More specifically, some of the arguments in this thread seem to be
centered around structuring your repository. Or more specifically, the
fact that Subversion does not force you to operate in any pre-determined
method. For command line tools, this is usually a blessing and for
GUI's this is usually a curse.
With the few other version control systems that do offer this amount of
flexibility, you need a controlling script in order to do something
highly specific with the command line tool. One of the weaknesses of
this approach is that the collection scripts to do these types of
operations is not well maintained. And in most cases, even finding the
script you are looking for is problematic because the author's site is
gone or fallen into disrepair. These problems should be relatively easy
to fix with the right community support.
[insert shameless plug]
One of the idea's that I've been kicking around specifically for GUI
applications, is for a schema that defines the layout of the
repository. While the un-official (possibly offical now?)
recommendation is for the "project/ tags, branches, trunk" layout (do we
have a name for this?), I am sure that someone will find a way to use
this flexibility to enhance their development model. Being able to
describe this layout so that nearly all off the shelf GUI tools work
with your custom repository appears to be a big advantage to me. This
could help in freeing groups from thinking about whether Subversion can
support their development model, and start encouraging them to come up
with new ways to enhance their development model.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Summarizing the gigantic "Dropping Subversion" thread
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 12-04-2004 14:09, Erik Huelsmann wrote:
> > I'd rather not have to learn all these deep layers of subversion to get
> > basic information.
>
>Maybe what you require is not that basic anymore? :-)
The information is basic, dare I say fundamental, no one should need to
look further then the client API to get it. I think I heard that it
would be best in the client API but its not there yet.
Should I add an issue to have the client API be able to split a URL
into its two parts, access-to-repo, path-in-repo?
Should I add an issue to have changed paths return URL's and not
repo-paths?
BArry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Summarizing the gigantic "Dropping Subversion" thread
Posted by Erik Huelsmann <e....@gmx.net>.
Hi,
> But I'd guess that its not a goof idea to have clients get to know about
> the details deep in as it makes updating the API's in the future that
> much harder.
There is a very strict ruleset which defines how and when APIs can be
updated. Your client using them makes no difference to the ruleset. Besides: The
ruleset is in place so that you can depend on the presence of this API. The
rules are described in the HACKING document in the section "Release numbering,
compatibility, and deprication".
> I'd rather not have to learn all these deep layers of subversion to get
> basic information.
Maybe what you require is not that basic anymore? :-)
bye,
Erik.
--
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/info
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Summarizing the gigantic "Dropping Subversion" thread
Posted by Barry Scott <ba...@barrys-emacs.org>.
But I'd guess that its not a goof idea to have clients get to know about
the details deep in as it makes updating the API's in the future that
much harder.
I'd rather not have to learn all these deep layers of subversion to get
basic information.
Barry
At 12-04-2004 01:20, Greg Hudson wrote:
>On Sat, 2004-04-10 at 10:06, Barry Scott wrote:
> > At 10-04-2004 02:58, Greg Hudson wrote:
> > >On Thu, 2004-04-08 at 18:56, Barry Scott wrote:
> > > > svn_client_ls needs replacing as its return is ambiguous.
> > > > svn_client_log changed_paths output is not usable as you cannot figure
> > > > out the repo URL to use. Need API to return root of repo.
> > >
> > >We have one in the svn_ra API, though not (that I could find) in the
> > >svn_client API.
> >
> > Are you saying there is a solution in 1.0.x or that this needs adding
> > to the svn_client API before there is a solution?
>
>I'm saying there is a solution, but it's not as convenient to use
>(because it lives in a deeper API) as if, say, svn_client_log returned a
>URL for the repository root.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Summarizing the gigantic "Dropping Subversion" thread
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2004-04-10 at 10:06, Barry Scott wrote:
> At 10-04-2004 02:58, Greg Hudson wrote:
> >On Thu, 2004-04-08 at 18:56, Barry Scott wrote:
> > > svn_client_ls needs replacing as its return is ambiguous.
> > > svn_client_log changed_paths output is not usable as you cannot figure
> > > out the repo URL to use. Need API to return root of repo.
> >
> >We have one in the svn_ra API, though not (that I could find) in the
> >svn_client API.
>
> Are you saying there is a solution in 1.0.x or that this needs adding
> to the svn_client API before there is a solution?
I'm saying there is a solution, but it's not as convenient to use
(because it lives in a deeper API) as if, say, svn_client_log returned a
URL for the repository root.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Summarizing the gigantic "Dropping Subversion" thread
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 10-04-2004 02:58, Greg Hudson wrote:
>On Thu, 2004-04-08 at 18:56, Barry Scott wrote:
> > svn_client_ls needs replacing as its return is ambiguous.
> > svn_client_log changed_paths output is not usable as you cannot figure
> > out the repo URL to use. Need API to return root of repo.
>
>We have one in the svn_ra API, though not (that I could find) in the
>svn_client API.
Are you saying there is a solution in 1.0.x or that this needs adding
to the svn_client API before there is a solution?
BArry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Summarizing the gigantic "Dropping Subversion" thread
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2004-04-08 at 18:56, Barry Scott wrote:
> svn_client_ls needs replacing as its return is ambiguous.
> svn_client_log changed_paths output is not usable as you cannot figure
> out the repo URL to use. Need API to return root of repo.
We have one in the svn_ra API, though not (that I could find) in the
svn_client API.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Summarizing the gigantic "Dropping Subversion" thread
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 07-04-2004 07:21, Brandon Ehle wrote:
>3) It takes more effort to do operation FOO in Subversion than in source
>control Z.
There are cases that cannot be solved at all until new API functions are added.
Theses are the ones that have already been discussed already.
svn_client_ls needs replacing as its return is ambiguous.
svn_client_log changed_paths output is not usable as you cannot figure
out the repo URL to use. Need API to return root of repo.
No formal concept of label that can be used by all tools (raised on user list
and needs discussing on dev list).
>More specifically, some of the arguments in this thread seem to be
>centered around structuring your repository. Or more specifically, the
>fact that Subversion does not force you to operate in any pre-determined
>method. For command line tools, this is usually a blessing and for GUI's
>this is usually a curse.
Its not the structure of the repo, it is being able to access a class of
information
about the repo that is important, the info for example that I want is labels.
I don't care that the repo structure is, or if someone uses labels, only that
if they do there is one way to get the label info. (using cp to /tags to create
a label does not work as there is no easy way to work from a item and find all
the copies. The logs record come_from's not goto's).
>[insert shameless plug]
>
>One of the idea's that I've been kicking around specifically for GUI
>applications, is for a schema that defines the layout of the
>repository. While the un-official (possibly offical now?) recommendation
>is for the "project/ tags, branches, trunk" layout (do we have a name for
>this?), I am sure that someone will find a way to use this flexibility to
>enhance their development model. Being able to describe this layout so
>that nearly all off the shelf GUI tools work with your custom repository
>appears to be a big advantage to me. This could help in freeing groups
>from thinking about whether Subversion can support their development
>model, and start encouraging them to come up with new ways to enhance
>their development model.
Sorry I don't agree. I think that as we innovate usage of subversion any layout
you try to suggest will be inappropriate. For example I would use a layout that
splits trunk into two, Latest and Stable. Latest is where one checks in as
often
as you want Stable is merged from Latest and is expected to work. Like svk in
one repo. (I'm waiting on the 1.1 merge fixes to have this work well).
Get the meta data and API right and it does not matter what the repo
structure is.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Summarizing the gigantic "Dropping Subversion" thread
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-04-07 at 01:21, Brandon Ehle wrote:
> One of the idea's that I've been kicking around specifically for GUI
> applications, is for a schema that defines the layout of the
> repository. While the un-official (possibly offical now?)
Yes, it's official. It's what the development team "officially"
recommends, and the book recommends as well. I even rewrote the entire
book branching chapter to use this layout in its examples.
> recommendation is for the "project/ tags, branches, trunk" layout (do we
> have a name for this?),
Yes, it's called a "project root". A project root can exist anywhere in
a repository: by definition, it contains three subdirs: trunk,
branches, tags.
> Being able to describe this layout so that nearly all off the shelf GUI
> tools work with your custom repository appears to be a big advantage
> to me.
...and this is exactly why we have this official recommendation.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org