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
Received on Fri Apr 9 01:41:38 2004