[ https://jira.jboss.org/jira/browse/DNA-240?page=com.atlassian.jira.plugin... ] Serge Emmanuel Pagop updated DNA-240: ------------------------------------- Fix Version/s: 0.4 (was: 0.3) Affects Version/s: 0.4 (was: 0.3) move to 0.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-240?page=com.atlassian.jira.plugin... ] Randall Hauch commented on DNA-240: ----------------------------------- I'll add some thoughts, since I've written the workspace support for other connectors. There are a couple of useful things around the concept of DNA workspaces (which follow JCR workspaces, btw). The first is that a single RepositorySource can "contain" (or expose) one or more workspaces to the rest of the system; the available workspaces are returned in the GetWorkspacesRequest. The second is that the workspaces in a source can either be fixed or variable; there is a connector capability that says whether the connector can create workspaces, and the source can support the CreateWorkspaceRequest, DestroyWorkspaceRequest, and CloneWorkspaceRequest commands. The third is that sources typically have a "default" workspace that is used when the VerifyWorkspaceRequest contains null for the workspace name. Finally, there is the notion about how the content of workspaces are related to each other. Basically, workspaces are independent, but it is possible that a node in one workspace has what JCR calls "corresponding nodes" in other workspaces. You can think of these as a node in one workspace that has the same identity (e.g., UUID) as a node in another workspace. All other aspects of these nodes (e.g., properties, children, etc.) are independent. So, given these characteristics, it seems to make sense that a DNA workspace maps pretty well to an SVN branch/tag. This is especially true given that a file in one branch may also "correspond to" a file in a different branch. So, assuming the SVN repository uses the "convention" of a "trunk", "branches" and "tags" folder structure, then there would be one workspace for "trunk", and one workspace for each branch and each tag. The default workspace would be "trunk" (meaning that processing a VerifyWorkspaceRequest would treat a null workspace name as if it were "trunk"). Although it'd be possible for the connector to allow creating workspaces, in the short term all I think we need/want is the ability for the connector to expose the existing trunk, branches and tags. Therefore, the connector capabilities would say that no workspaces can be created, and the processing of the CreateWorkspaceRequest, DestroyWorkspaceRequest, and CloneWorkspaceRequest would throw exceptions. (Note that if we would want to allow the connector to create new branches or tags, then these requests map pretty closely to the kinds of SVN operations to create a branch/tag.) Finally, the GetWorkspacesRequest would simply return the names of the branches, tags and "trunk". BTW, in order to make the workspace name more meaningful to the user, the connector could use a convention where the workspace names could follow a pattern; e.g., "branch/xyz" where "xyz" is the actual branch name, and "tag/abc" where "abc" is the actual name of the tag. The SVNRepositorySource could also be configured to restrict the workspace names that should be exposed. For example, this could be done as a single String[] property (see FileSystemSource.getPredefinedWorkspaceNames) of workspace names, or it could be done using more SVN terminology: a String[] exposedBranches, a String[] exposedTags, and a boolean exposeTrunk. This is just one suggestion; there certainly are other good possibilities. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-240?page=com.atlassian.jira.plugin... ] Randall Hauch updated DNA-240: ------------------------------ Fix Version/s: 0.6 (was: 0.5) Retargeting to fix in 0.6, since 0.5 has been shortened and made more focused. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-240?page=com.atlassian.jira.plugin... ] Randall Hauch updated DNA-240: ------------------------------ Fix Version/s: 0.6 (was: 0.7) Priority: Critical (was: Major) As requested from user community, this is back into 0.6. Changing priority to 'critical'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/DNA-240?page=com.atlassian.jira.plugin... ] Randall Hauch resolved DNA-240. ------------------------------- Resolution: Done Assignee: Randall Hauch (was: Serge Emmanuel Pagop) Marking as resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira