WebDAV MERGE method use cases. Merge with simple conflict To merge main.c from the bugfix workspace into the project1 workspace the client would issue.

Slides:



Advertisements
Similar presentations
1 IST 410/420 Software Version Control 2 DevelopmentIntegration Test System Test User Acceptance Testing ProductionArchive DEVELOPMENTUSERS - Developers.
Advertisements

TCP/IP Protocol Suite 1 Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter 22 World Wide Web and HTTP.
Dedi Rahmawan Putra  Shared Document  Conventional Ways  Common Problems  What is TortoiseSVN  Advantages over another tools  Basic Concepts.
2/6/2008Prof. Hilfinger CS164 Lecture 71 Version Control Lecture 7.
Version Control and Subversion Chris Coakley. Outline What is Version Control? Why use it? Using Subversion (SVN)
Microsoft Visual Source Safe 6.01 Microsoft Visual Source Safe (MVSS) Presented By: Rachel Espinoza.
1 Copyright © 2014 Tata Consultancy Services Limited Source Code Management using Rational Team Concert IBM Rational, Alliance & Technology Unit 2 July.
By Steven Campbell and Erik Boone.  Sharing projects by putting them into a central repository.  Checking out copies of projects from the repository.
Version Control. What is Version Control? Manages file sharing for Concurrent Development Keeps track of changes with Version Control SubVersion (SVN)
Source Code Revision Control Software CVS and Subversion (svn)
Version Control with git. Version Control Version control is a system that records changes to a file or set of files over time so that you can recall.
Git for Version Control These slides are heavily based on slides created by Ruth Anderson for CSE 390a. Thanks, Ruth! images taken from
Version Control with Subversion. What is Version Control Good For? Maintaining project/file history - so you don’t have to worry about it Managing collaboration.
Web-based Software Development Web-based Distributed Authoring and Versioning Jul 19, 2005 Shin Young Ahn.
Subversion. What is Subversion? A Version Control System A successor to CVS and SourceSafe Essentially gives you a tracked, shared file system.
Introducing Dreamweaver MX 2004
Tutorial 1 Getting Started with Adobe Dreamweaver CS3
1 DeltaV: Adding Versioning to the Web Jim Whitehead University of California, Santa Cruz
WWW Distributed Authoring and Versioning (WEBDAV ): An Introduction Jim Whitehead, U.C. Irvine Chair, IETF WEBDAV Working Group.
Subversion (SVN) Tutorial for CS421 Dan Fleck Spring 2010.
Warmup A programmer’s wife tells him, “Would you mind going to the store and picking up a loaf of bread? Also, if they have eggs, get a dozen.” The programmer.
DELTA-V Web Versioning and Configuration Management Working Group Jim Amsden.
Version control Using Git Version control, using Git1.
Git workflow and basic commands By: Anuj Sharma. Why git? Git is a distributed revision control system with an emphasis on speed, data integrity, and.
Object-Oriented Analysis & Design Subversion. Contents  Configuration management  The repository  Versioning  Tags  Branches  Subversion 2.
ClearCase Basics XML presentation.
Version Control Systems with Subversion (SVN) and Tortoise.
Version Control Menggunakan TortoiseSVN
Copyright © 2015 – Curt Hill Version Control Systems Why use? What systems? What functions?
SENG 403 Tutorial 1 1SENG 403 – Winter Agenda Version Control Basics Subversion Basic actions in Subversion Some examples 2SENG 403 – Winter 2012.
FILES AND ASSETS PANELS
CVS – concurrent versions system Network Management Workshop intERlab at AIT Thailand March 11-15, 2008.
CSE 219 Computer Science III CVS
ClearCase Concepts and Terminology
Version Control with SVN Images from TortoiseSVN documentation
Refactoring and Synchronization with the StarTeam Plug-in for Eclipse  Jim Wogulis  Principal Architect, Borland Software Corporation.
OLE Slide No. 1 Object Linking and Embedding H OLE H definition H add other information to documents H copy.
WebDAV Collections December 10, 1998 Judy Slein
1 MSTE Visual SourceSafe For more information, see:
Developer Best Practices R.SANTHANA GOPALAN. Developer Best Practices What is Workspace ? The directory where the developer edit the source files, compile,
2136 Gallows Road, Suite F, Dunn Loring, VA Phone: Fax: Business Analyst Training 1 Module 5.2 Rational ClearCase.
The top four lines are required if you are coding in XHTML and want to validate. Copy and paste them as the top four lines in the code you are writing.
Introduction to Git Yonglei Tao GVSU. Version Control Systems  Also known as Source Code Management systems  Increase your productivity by allowing.
WinCVS Training è Basic Concepts è Download & Setup è Importing a new module into CVS Repository è Getting new module from CVS è Getting Latest version.
22 Copyright © 2008, Oracle. All rights reserved. Multi-User Development.
1 Shuaib Karim Institute of Software Technology & Interactive Systems (Vienna University of Technology)
Session #2482 Implementing WebDAV Using J2EE TM and Open Source Technologies Juergen Pill Team Leader Software AG Remy Maucherat Software Engineer Sun.
TEAM FOUNDATION VERSION CONTROL AN OVERVIEW AND WALKTHROUGH By: Michael Mallar.
Subversion (SVN) Tutorial for CS421 Dan Fleck Spring 2010.
1 Ivan Marsic Rutgers University LECTURE 2: Software Configuration Management.
CS520 Web Programming Version Control with Subversion Chengyu Sun California State University, Los Angeles.
1 Subversion Kate Hedstrom April Version Control Software System for managing source files –For groups of people working on the same code –When.
BOF-1147, JavaTM Technology and WebDAV: Standardizing Content Management Java and WebDAV Juergen Pill Team Leader Software AG Remy Maucherat Software Engineer.
Configuration Management
Version Control with Subversion
SVN intro (review).
LECTURE 2: Software Configuration Management
Source Control Dr. Scott Schaefer.
Concurrent Version Control
Akshay Narayan git up to speed with RCS Akshay Narayan
LECTURE 3: Software Configuration Management
The Big Picture
Viney Sindhu Dr. Yanqing Zhang
Revision Control Daniel Daugherty
March 17, 1999 Judy Slein WebDAV Collections March 17, 1999 Judy Slein
WebDAV Collections Breakout Session
WebDAV Design Overview
Versioning and Variant Authoring Requirements
Concurrent Versions System
Presentation transcript:

WebDAV MERGE method use cases

Merge with simple conflict To merge main.c from the bugfix workspace into the project1 workspace the client would issue a MERGE request with the target being /dav/vcr/project1/main.c and DAV:source being /dav/vcr/bugfix/main.c. This would CHECKOUT the VCR in the project1 workspace, and set it’s DAV:merge-set to include V2.2 and V4. It is the clients responsibility to physically merge the file contents and properties (PUT and PROPPATCH the checked-out VCR) and move the version URLs from the merge-set to the predecessor-set. The client must then explicitly CHECKIN the VCR. This is described in the protocol in the postcondition DAV:checked-out-for-merge. Version History Resource /dav/his/h1 V4 V3 V1 V2 V2.1 V2.2 Version Controlled Resource /dav/vcr/bugfix/main.c DAV:checked-in This is a VCR for main.c in workspace “bugfix”. It’s checked-in version is V2.2. Version Controlled Resource /dav/vcr/project1/main.c This is a VCR for main.c in workspace “project1”. It’s checked-in version is V4. DAV:checked-in

Merge with no conflict The file foo.c has been edited to create V4 in a “bugfix” workspace and that fix needs to be included back into the main project1 workspace. The client would issue a MERGE request with target being /dav/vcr/project1/foo.c and DAV:source being /dav/vcr/bugfix/foo.c. This would simply UPDATE the VCR /dav/vcr/project1/foo.c so that it’s content and dead properties reflect that of V4 and it’s DAV:checked-in version would be V4. This is described in the protocol on the postcondition DAV:descendant-version. V4 V3 V1 V2 Version History Resource /dav/his/h2 Version Controlled Resource /dav/vcr/project1/foo.c This is a VCR for main.c in workspace “project1”. It’s checked-in version is V3. DAV:checked-in Version Controlled Resource /dav/vcr/bugfix/foo.c DAV:checked-in This is a VCR for main.c in workspace “bugfix”. It’s checked-in version is V4.

No merge needed The file foo.c has been edited to create V4 in the “project1” workspace and the bugfix workspace is being merged back into the main project1 workspace. The client would issue a MERGE request with target being /dav/vcr/project1/foo.c and DAV:source being /dav/vcr/bugfix/foo.c. This would not result in any UPDATE or CHECKOUT operation since V4 is a descendent of V3 and by definition there is no need for a merge. This is described in the protocol as postcondition DAV:ancestor-version. V4 V3 V1 V2 Version History Resource /dav/his/h2 Version Controlled Resource /dav/vcr/project1/foo.c This is a VCR for main.c in workspace “project1”. It’s checked-in version is V4. DAV:checked-in Version Controlled Resource /dav/vcr/bugfix/foo.c DAV:checked-in This is a VCR for main.c in workspace “bugfix”. It’s checked-in version is V3.

No changes made The file foo.c has not been edited in either workspace and the checked-in versions of the VCRs point to the same version. If the client makes a MERGE request on either VCR no CHECKOUT or UPDATE will take place. I cannot see a pre or post condition covering this in the protocol but it seems logical. V4 V3 V1 V2 Version History Resource /dav/his/h2 Version Controlled Resource /dav/vcr/project1/foo.c This is a VCR for main.c in workspace “project1”. It’s checked-in version is V4. DAV:checked-in Version Controlled Resource /dav/vcr/bugfix/foo.c DAV:checked-in This is a VCR for main.c in workspace “bugfix”. It’s checked-in version is also V4.

Merge of two collections In this scenario the client wants to merge a whole directory structure of code from the bugfix workspace into the project1 workspace. The checked-in versions of the files may differ in the different workspaces and the bugfix workspace does not contain the file inc.h. The client should issue a MERGE request with /dav/vcr/project1/build as the target and /dav/vcr/bugfix/build as the DAV:source. For each member of the source collection the server will find a VCR (if any) in the target collection that points to the same version history. The server will CHECKOUT or UPDATE each VCR in the project1 workspace setting their DAV:merge-set. The client is responsible for updating the checked-out VCRs properties and content, setting their predecessor set and checking them back in again. Collection Resource /dav/vcr/project1/build foo.c main.c inc.h images splash.jpg Collection Resource /dav/vcr/bugfix/build foo.c main.c images splash.jpg This collection has members that are VCRs for foo.c, main.c and inc.h, it also contains another collection called images which in- turn includes a VCR for the file splash.jpg. This collection includes members that are VCRs for the files foo.c and main.c, it also contains the images collection which also includes a VCR for the file splash.jpg.

Merge of additional files In this scenario the client wants to merge a whole directory structure of code from the bugfix workspace into the project1 workspace. The source collection has an additional file glob.c but according to the definition of the deltav MERGE method the new VCR would not be included in the target (because there is no VCR which shares the same Version History in the target collection). This seems wrong, the client must manually copy the resource to get it into the project1 workspace. See the 5 th paragraph of section 11.2 (but this is not defined in any pre or post condition. Collection Resource /dav/vcr/project1/build foo.c main.c inc.h images splash.jpg Collection Resource /dav/vcr/bugfix/build foo.c main.c This collection has members that are VCRs for foo.c, main.c and inc.h, it also contains another collection called images which in- turn includes a VCR for the file splash.jpg. This collection includes members that are VCRs for the files foo.c and main.c, it also contains the images collection which also includes a VCR for the file splash.jpg. inc.h images splash.jpg glob.c

Merge with multiple sources In this scenario the client wants to merge two specific files from the bugfix workspace into the project1 workspace. The checked-in versions of the files may differ in the different workspaces. The client should issue a MERGE request with /dav/vcr/project1/build as the target and /dav/vcr/bugfix/build/foo.c and /dav/vcr/bugfix/build/inc.h as the DAV:source. For each VCR in the DAV:source property the server will find a VCR (if any) in the target collection that points to the same version history. The server will CHECKOUT or UPDATE each VCR in the project1 workspace setting their DAV:merge-set. The client is responsible for updating the checked-out VCRs properties and content, setting their predecessor set and checking them back in again. Collection Resource /dav/vcr/project1/build foo.c main.c inc.h images splash.jpg This collection has members that are VCRs for foo.c, main.c and inc.h, it also contains another collection called images which in- turn includes a VCR for the file splash.jpg. Version Controlled Resource /dav/vcr/bugfix/build/foo.c Version Controlled Resource /dav/vcr/bugfix/build/inc.h