OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Your SVN version control instance is all set

On Tuesday 07 July 2015 13:55:39 Chet Ensign wrote:
> Members of the ODF TC,
> As requested, we have set up an SVN instance for you. You can access it at
> https://tools.oasis-open.org/version-control/browse/wsvn/office/?sc=0
> I've also added a link to "Version control" to the TC's web page and added
> it to the list of TC tools.

Thanks you Chet. I have just add a short README to the repository, purely as a 
test to see how/if it works. It works fine.

To check out the repository from subversion, I simply used:

  svn checkout https://tools.oasis-open.org/version-control/svn/office/
  cd office

To add data, I did this:

  svn add README
  svn commit README

The last command opens a text editor where a commit message can be written.

To get the latest version, run
  svn update

The credentials for svn are the same ones as for the OASIS website, i.e. not 
the JIRA credentials.

The repository comes with the standard SVN folder layout:


'trunk' contains the current most important branch. In our case this is the 
branch ODF 1.3.
'branches' contains work in progress. This can be work that goes towards trunk 
or work that goes towards another branch.
'tags' contains releases.

Putting our work in Subversion could be done with a folder layout like this:

    v1.0 Errata 03/
    v1.0 Errata 03 OFFICE-3739/
    v1.1 Errata 02/
    v1.2 Errata 01/
    v1.2 Errata 01 OFFICE-3674/
    v1.3 OFFICE-2183/
    next OFFICE-3556/
    v1.0 second edition/
    v1.0 Errata 01/
    v1.0 Errata 02/
    v1.1 Errata 01/
'branches' contains two types of branches. The current state of each version 
is available in 'v1.0 Errata 03', 'v1.1 Errata 02', 'v1.2 Errata 01', 'v1.3' 
and 'next'. Each unresolved issue in JIRA will have a branch too. When the 
issue is accepted, the branch is merged into the branch of the respective 
version. When a version is released, it moves to 'tags'.

The assignees of the JIRA issues are should put their changes in the 
respective OFFICE branch (or mail the changes to a chair who can do it). The 
tc chair is responsible for merging the branches when they are accepted by the 

For the initial contents of 'trunk' and the releases in 'tags', I've not come 
up with a folder structure yet. Suggestions are welcome. It is best to put the 
ODF in unzipped and indented form in SVN.

There are a number of tools for working with the specification. I'd like to 
have a discussion with Patrick what these are exactly and then come up with a 
folder structure for a repository that contains the tools.

I tend to thinking that we should keep the tools in a separate repository 
since changes to the tools are valuable for all branches and so versioning of 
the tools should be independent of the versioning of the specification.

Best regards,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]