Hi Thomas,
On Sat, 30 Jul 2005, Thomas Beale wrote:
> Robert P. J. Day wrote:
> > On Sat, 30 Jul 2005, Thomas Beale wrote:
> >
> > as more than one person has pointed out, there's nothing magical about
> > directories named "Branches" or "Tags" or "Releases" -- it's all in
> > the way you treat them, that's all.
>
> But there should. The formal semantics of these directories are not
> those of a normal project directory; they are there to separate out
> different branches of development, and also to implement tags. But the
> semantics of these things are not the semantics of directories.
But from the point of view of a versioned filesystem, there is no
difference in the semantics of these two directories in the versioned
filesystem tree. The precise location in the versioned virtual filesystem
tree of a specific variation on a given file is irrelevant for the
purposes of efficient storage of all the different versions of that file
in all locations plus their inter-relationships. SVN supplies mechanism.
SVN knows nothing of your policy, formal semantics or development
methodologies, and I claim it should never be made to know of them.
However as you say, the 'true filesystem' content directories as seen in a
WC and the 'virtual filesystem' meta-content directories as seen in the
server's repository structure are very different types of object when seen
from a SCM point of view. At this level of abstraction they do have
different semantics. But that has little to do with SVN any longer; that's
policy of an SCM, not mechanism of a versioned filesystem.
So this is not (as you said earlier) a confusion in SVN between two
different concepts, which could lead to bugs etc down the track. Instead,
at the level of abstraction at which SVN currently operates, there is
simply no distinction between these two concepts, and therefore there is
no design flaw inherent in treating them identically in SVN as it
currently stands. Do you agree? Or so you still see this as a
confusion and/or design bug in SVN?
In your latest message, you appear to be arguing:
1. I need a software configuration management system.
2. SVN is only a version control system, not a full SCM.
3. Therefore, SVN should become a full SCM system.
By this argument, we would soon end up with the kernel and all apps
statically linked together in one address space. I'm sure you'll agree
that modularity leads to better quality software, so a better argument is:
1. I need a software configuration management system.
2. SVN is only a version control system, not a full SCM.
3. But umodified SVN can be used as a base on which to implement SCM.
4. Therefore, SVN should be used as a base for higher SCM layers.
Then the SVN and SCM layers can be more easily debugged and tested.
AFAICS, if you really need your policy to be enforced in software at some
level, not just adhered to because of sufficient user training, then this
all necessitates just the sort of breakdown you describe:
> - bottom layer: subversion as it is now (don't touch it!)
> - Configuration Management semantics layer: a layer which uses the
> subversion version controlled file system to store data, but adds CM
> semantics, rather like BitKeeper does (it just uses SCCS files in fact,
> plus a whole lot of control data, and makes it look like multiple
> parallel branches all going on
> - front-end (client) layer: where configuration / localisation of
> workflow, process, branche types etc is done.
>
> I guess the way I would implement the CM semantics I think should exist
> would be an independent (optional) architectural layer on top of
> subversion's backend.
It seems to me that if you only used the command-line client, your middle
tier could be at minimum a bunch of fairly trivial shell scripts of the
sort that someone else just posted. Do you want a copy of our wrapper
scripts too? They're pretty similar. They're *very* easy to use.
A better design, though, would be to merge your CM tier into your client
tier, in a new client app. There would be a new layer between the
top-level UI, and the RA layer, which would enforce policy. Much of the
RA layer's functionality would be hidden and aggregated together into
even-higher-level operations of the sort you want, and then only those
even-higher-level operations would be accessible from the client UI.
For example a 'release' operation, which just knows the policy for
where in the repository tree release tags live, as opposed to
TortoiseSVN's branch/tag operation, which gives you the unfortunate
freedom to violate site policy by creating tags in the wrong place.
One single client policy configuration file should describe the project
structure, map the project structure to the repository structure, and
describe the allowed workflow.
I encourage you to create such a client program. With reference to the
TortoiseSVN source for guidance, it should not be too difficult or
time-consuming.
Generally, if your needs can be satisfied solely by adding more
functionality on top of subversion (without actually changing subversion
itself), then you have not thereby necessarily discovered a design flaw in
Subversion, don't you agree?
Instead, you have discovered a way to use svn plus some extra
functionality to address problems that svn (by design) does not currently
attempt (and should never attempt IMO) to address.
Regards,
--m@
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 1 04:08:41 2005