[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Per-project metadata (Was: SV: .svn directories)

From: Jesper Bork <Jesper.Bork_at_eu.fkilogistex.com>
Date: 2003-08-27 09:25:49 CEST

With per-project meta-data I refer to any data that the SCM needs to manage
a project. The approach taken by CVS and Subversion is - as far as I
understand it - to use decentralized data meaning that due to the meta-data
held in the .svn directories, a workspace knows what repository "it belongs
to". On the other hand, a repository does not know how many workspaces has
been created from that repository or where they are located or what state it
is in (at least this is what I assumes is the case). This is opposed to e.g.
centralized nature of e.g. MS SourceSafe, where you in the GUI can see who
has checked something out, when ,and where (actually, I don't think you can
see how many workspaces exists and where - only checked out assets). While
the decentralized approach provides a technically clean solution without
"dangling locks", the centralized approach provides many
organizational/team-oriented benefits.

The reason for proposing centralized statistics or maybe just accessible
from a central point would be that that information is not in any way
essential to the operating of the tool, i.e. no danger of "dangling locks",
even if that information became inaccurate, but very often used outside of a
particular project context, e.g. by a tools responsible.

My interpretation of intrusiveness of meta-data is measured by primarily the
number of occurrences of "foreign data" in my source code branch, and to a
lesser degree also the amount of that data. By non-intrusive meta-data I
mean that which I can choose to locate inside my project, but outside my
source branch. I am aware that this is a highly subjective matter, however,
for many reasons including those mentioned by Kumaran, I believe that the by
far best approach is to allow meta-data such as the .svn directories to be
located at a place specified by the project owner who may then point out the
source branch(es) to the tool.

Jesper Bork
FKI Logistex
Crisplant Software Dept.

-----Original Message-----
From: Jack Repenning [mailto:jrepenning@collab.net]
Sent: 26. august 2003 18:03
To: Jesper Bork; 'Kumaran Santhanam'
Cc: 'dev@subversion.tigris.org'
Subject: Per-project metadata (Was: SV: .svn directories)

At 9:38 PM +0200 8/25/03, Jesper Bork wrote:
>
>Much in line with your thoughts and from years of experience from a
>project-centered environment handling around 25 projects a year, I
>believe that an SCM provides the maximum overall benefit in a
>commercial environment by combining the loose coupling of the
>copy-modify-merge source code approach taken by CVS and Subversion
>together with decentralized non-intrusize per-project meta-data and
>finally centralized statistics allowing e.g. project managers and
>method & tools depts. to get an overall view of e.g. repository
>status. While avoiding locks due to going on holidays while having
>something checked out is a technical issue, it is still an
>organizational issue to catch the guy doing that or maybe - as we
>allow - taking charge of someone elses workspace, if necessary to
>get the project moving.

I get most of that, but what do you mean by "decentralized
non-intrusive per-project meta-data"? Can you give some examples of
the meta-data you're thinking of, how they don't intrude (or, how
other data _do_ intrude, I suppose)?

-- 
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
Received on Wed Aug 27 15:09:36 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.