SVN-Related Practices and Customs

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Bart,

You created the current oic SVN top-level of trunk/, tags/, and branches/.  I was wondering if that was just an automatic replication of a common SVN practice or whether you have a strong requirement for using that structure across the SVN.

I ask because my preference is to add the SpecAnalysis tree at the top level and not force it to be synchronized under a global trunk/, tags/ and branches/ scheme.

Does it work for you and others if I put SpecAnalysis/ at the top of the oic SVN, making it a peer of the current trunk/, tags/, and branches/ folders?

I will put off creating the SpecAnalysis tree for a day or two while we mull this over.

 - Dennis

MORE DISCUSSION:

It seemed to me that we don't want a single trunk for everything, maybe not even for much, since what we are doing is more like several projects in the usual source-code-management sense.  I suspect that people will be working in topical or thematic subtrees rather than the full tree for the most part.  In particular, I suspect that branching and labeling, if ever done, happens at deeper levels.  Also, many people will create working folders for only the parts of the tree that interests them.

It is my thinking to put SpecAnalysis and its subordinates at the top level (not under the trunk), deferring the creation of labels and branches to somewhere lower.  One consequence is that the main tree will simply be trunk by default and that any labels and branches will be peers of "trunk" levels (whether submerged under folders of those names or handled another way).  

Apparently SVN could care less, although there does need to be some forethought on when and where labels and branches might arise.  This seems to be important only if merging from a branch is anticipated.  There may need to be some consideration to how svn:external might be relied upon to "share" content between versions.  That prospect might be valuable to preserve (e.g., for 1.1 tests that are also 1.2 tests, although the reorganization of 1.2 into three parts will also be challenging to match up against). 

That's a lot to get our head around at first.  I reviewed the SVN information I have and I'm satisfied that if trunk layers need to be explicitly added to the SpecAnalysis tree, that can always be done on an as-needed basis.  However, linking into the SVN tree from the wiki, for example, is impacted if URLs into the SVN need to be updated as a consequence.  (URLs will also have to be updated in moving a wiki link from the trunk to a tag, so maybe this is just an inevitable bother and not something that can be safeguarded against.)

-----Original Message-----
From: workgroup_mailer@lists.oasis-open.org [mailto:workgroup_mailer@lists.oasis-open.org] 
http://lists.oasis-open.org/archives/oic/200902/msg00064.html
Sent: Monday, February 23, 2009 04:38
To: oic@lists.oasis-open.org
Subject: [oic] Version Control Commit by bart.hanssens

Author: bart.hanssens
Date: 2009-02-23 07:38:01 -0500 (Mon, 23 Feb 2009)
New Revision: 17
Web View: http://tools.oasis-open.org/version-control/browse/wsvn/oic/?rev=17&sc=1

Added:
   trunk/documents/ODF11-ch03-Metadata-barth.odp
   trunk/documents/ODF11-ch03-Metadata-barth.ods
   trunk/documents/ODF11-ch03-Metadata-barth.odt
Log:
added 3 test documents for ODF 1.1 Metadata (chapter 3)


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php