Matthew Sanderson wrote:
>Hi Thomas,
>
>
>
>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.
>
>
Agree; what is in the real server back-end should probably be just what
it is today. I just would not use that mechanism to implement the
semantics of branches, tags etc...
>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.
>
>
also agree...
>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?
>
>
well, I see it as an attempt to implement semantics in a very
approximate way in SVN's currently versioned fle system facility (likely
to cause problems) when such semantics should realy be implemented
elsewher - in another server layer, in the client or whatever.
>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.
>
>
well, not necessarily the last - it may be up to other groups to build
other layers. But on the other hand the subversion people do publish in
their book the file-system implementation of branches and tags, which
indicates they are thinking about such issues.
>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.
>
>
I alreayd suggested this in another post (maybe it was not clear
enough). But I agree anyway.
>Then the SVN and SCM layers can be more easily debugged and tested.
>
>
I would never suggest anyhting else. This discussion, from my point of
view is about requirements, not (ye) about architecture.
......
>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 haven't had the time to think an architectural solution through, but
all this sounds very reasonable. One thing I am fairly sure of: there
would not be any "tags" directory; I would simply record the tag against
the revision number being tagged. Of course this mitigates against using
multiple project trees in one repository, which I initially thought
sounded good, but in the end I think is unusable; it has to be one
project per repository. Doing otherwise renders the versioning across
the board completely meaningless, and means that svn really is just a
versioned file-system (and I'm not knocking that!).
>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?
>
>
I don't think there is a design flaw in subversion, but I do think there
is a flaw in the design thinking of the total solution to implement
trunk/branches/tags as plain old directories.
>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.
>
>
which I agree is the correct way to see things. When I have time, I will
indeed consider how this functionality can be added, and share it with
the group.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 1 11:47:24 2005