Talk:Scenarios for Team-based Development - Revision history

imported>Mathieu: /* mercurial configuration sample */ replace & by &

2010-03-02T09:19:51Z

mercurial configuration sample: replace & by &

← Older revision		Revision as of 09:19, 2 March 2010
Line 69:		Line 69:
	output=`echo $5\| tr -d '"' `		output=`echo $5\| tr -d '"' `
	echo tdm "$1" "$2" "$3" "$4" "$5"		echo tdm "$1" "$2" "$3" "$4" "$5"
	sed -i -e "s/ /##10;/g" "$output" "$local" "$base" "$other"		sed -i -e "s/&#10;/##10;/g" "$output" "$local" "$base" "$other"
	java -cp ${HOME}/java/java-getopt-1.0.12.jar:${HOME}/java/xercesImpl.jar:${HOME}/java/xmlParserAPIs.jar:${HOME}/java/3dm.jar tdm.tool.TreeDiffMerge $action "$base" "$local" "$other" "$output"		java -cp ${HOME}/java/java-getopt-1.0.12.jar:${HOME}/java/xercesImpl.jar:${HOME}/java/xmlParserAPIs.jar:${HOME}/java/3dm.jar tdm.tool.TreeDiffMerge $action "$base" "$local" "$other" "$output"
	#revert tdm side effects		#revert tdm side effects
	sed -i -e "s/ \/>/\/>/g" -e "s/'/'/g" -e "s/##10;/\ /g" "$output" "$local" "$base" "$other"		sed -i -e "s/ \/>/\/>/g" -e "s/'/'/g" -e "s/##10;/\&#10;/g" "$output" "$local" "$base" "$other"

	# if merge failed because of conflict		# if merge failed because of conflict

imported>Mathieu: /* mercurial configuration sample */

2009-01-25T21:22:45Z

mercurial configuration sample

← Older revision		Revision as of 21:22, 25 January 2009
Line 69:		Line 69:
	output=`echo $5\| tr -d '"' `		output=`echo $5\| tr -d '"' `
	echo tdm "$1" "$2" "$3" "$4" "$5"		echo tdm "$1" "$2" "$3" "$4" "$5"
			sed -i -e "s/ /##10;/g" "$output" "$local" "$base" "$other"
	java -cp ${HOME}/java/java-getopt-1.0.12.jar:${HOME}/java/xercesImpl.jar:${HOME}/java/xmlParserAPIs.jar:${HOME}/java/3dm.jar tdm.tool.TreeDiffMerge $action "$base" "$local" "$other" "$output"		java -cp ${HOME}/java/java-getopt-1.0.12.jar:${HOME}/java/xercesImpl.jar:${HOME}/java/xmlParserAPIs.jar:${HOME}/java/3dm.jar tdm.tool.TreeDiffMerge $action "$base" "$local" "$other" "$output"
	#revert tdm side effects		#revert tdm side effects
	sed -i -e "s/ \/>/\/>/g" -e "s/'/'/g" "$output" "$local" "$base"		sed -i -e "s/ \/>/\/>/g" -e "s/'/'/g" -e "s/##10;/\ /g" "$output" "$local" "$base" "$other"

	# if merge failed because of conflict		# if merge failed because of conflict

imported>Mathieu: /* mercurial configuration sample */ update, with real use configuration

2008-11-10T14:31:03Z

mercurial configuration sample: update, with real use configuration

@@ Line 31: / Line 31: @@
 ===mercurial configuration sample===
 <pre><nowiki>
 [merge-tools]
-xmlmerge.priority = 100
+xmlmerge.priority = 10
 xmlmerge.executable = tdm
 xmlmerge.premerge = False
-xmlmerge.args = -m $base $local $other $output
+xmlmerge.args = -m \"$base\" \"$local\" \"$other\" \"$output\"
 [merge-patterns]
 **.xml = xmlmerge
 **.svg = xmlmerge
 **.bum = xmlmerge
 **.buc = xmlmerge
-**.bpr = xmlmerge
+</nowiki></pre>
 </nowiki></pre>

imported>Mathieu: /* DVCS setup */

2008-10-03T13:09:11Z

DVCS setup

← Older revision		Revision as of 13:09, 3 October 2008
Line 25:		Line 25:
	=== DVCS setup ===		=== DVCS setup ===
	We are in the process of trying a setup of [http://www.selenic.com/mercurial/wiki/ Mercurial] with [http://tdm.berlios.de/3dm/doc/index.html ''3dm'']. 3dm has known shortcomings (notably when there are conflicts), but it does handle gracefully lot of cases (look at the examples in the source distribution). I hope to keep you informed of problems we will encounter, but we'll eventually at least need:		We are in the process of trying a setup of [http://www.selenic.com/mercurial/wiki/ Mercurial] with [http://tdm.berlios.de/3dm/doc/index.html ''3dm'']. 3dm has known shortcomings (notably when there are conflicts), but it does handle gracefully lot of cases (look at the examples in the source distribution). I hope to keep you informed of problems we will encounter, but we'll eventually at least need:
	* a way to resolve conflicts without seeing XML (for model ''and'' [[~~Scenario~~ for Merging Proofs\|proofs]]).		* a way to resolve conflicts without seeing XML (for model ''and'' [[Scenarios for Merging Proofs\|proofs]]).
	* a way to review automated merges (because computers do not understand the model semantic, and may do wrong merges)		* a way to review automated merges (because computers do not understand the model semantic, and may do wrong merges)
	* a way to review changes between two database snapshots (in order to browse change history, to see diff between working directory and current heads,... )		* a way to review changes between two database snapshots (in order to browse change history, to see diff between working directory and current heads,... )

imported>Mathieu: /* DVCS setup */

2008-10-02T20:04:20Z

DVCS setup

← Older revision		Revision as of 20:04, 2 October 2008
Line 25:		Line 25:
	=== DVCS setup ===		=== DVCS setup ===
	We are in the process of trying a setup of [http://www.selenic.com/mercurial/wiki/ Mercurial] with [http://tdm.berlios.de/3dm/doc/index.html ''3dm'']. 3dm has known shortcomings (notably when there are conflicts), but it does handle gracefully lot of cases (look at the examples in the source distribution). I hope to keep you informed of problems we will encounter, but we'll eventually at least need:		We are in the process of trying a setup of [http://www.selenic.com/mercurial/wiki/ Mercurial] with [http://tdm.berlios.de/3dm/doc/index.html ''3dm'']. 3dm has known shortcomings (notably when there are conflicts), but it does handle gracefully lot of cases (look at the examples in the source distribution). I hope to keep you informed of problems we will encounter, but we'll eventually at least need:
	* a way to resolve conflicts without seeing XML (for model ''and'' proofs).		* a way to resolve conflicts without seeing XML (for model ''and'' [[Scenario for Merging Proofs\|proofs]]).
	* a way to review automated merges (because computers do not understand the model semantic, and may do wrong merges)		* a way to review automated merges (because computers do not understand the model semantic, and may do wrong merges)
	* a way to review changes between two database snapshots (in order to browse change history, to see diff between working directory and current heads,... )		* a way to review changes between two database snapshots (in order to browse change history, to see diff between working directory and current heads,... )

imported>Mathieu: /* proposal draft */

2008-09-29T09:15:52Z

proposal draft

← Older revision		Revision as of 09:15, 29 September 2008
Line 23:		Line 23:
	:How will we translate UML elements into text ? Won't the bi-directional translator becomes more and more complex when the database will bear objects other than event and mathematical formulas ?		:How will we translate UML elements into text ? Won't the bi-directional translator becomes more and more complex when the database will bear objects other than event and mathematical formulas ?

	===~~proposal draft~~ ===		=== DVCS setup ===
	We are in the process of trying a setup of [http://www.selenic.com/mercurial/wiki/ Mercurial] with [http://tdm.berlios.de/3dm/doc/index.html ''3dm'']. 3dm has known shortcomings (notably when there are conflicts), but it does handle gracefully lot of cases (look at the examples in the source distribution). I hope to keep you informed of problems we will encounter, but we'll eventually at least need:		We are in the process of trying a setup of [http://www.selenic.com/mercurial/wiki/ Mercurial] with [http://tdm.berlios.de/3dm/doc/index.html ''3dm'']. 3dm has known shortcomings (notably when there are conflicts), but it does handle gracefully lot of cases (look at the examples in the source distribution). I hope to keep you informed of problems we will encounter, but we'll eventually at least need:
	* a way to resolve conflicts without seeing XML (for model ''and'' proofs).		* a way to resolve conflicts without seeing XML (for model ''and'' proofs).

imported>Mathieu: Reactions and thoughts

2008-09-29T09:11:16Z

Reactions and thoughts

New page

== Required scenarios ==
===Systerel===
As an industrial already using Rodin, we are in deep need of support for team-based development inside Rodin.
Scenarios ''(S-2)'', ''(S-3)'' and ''(S-4)'' are routinely used here on other projects, and we are trying to build a solution for Rodin (see below).

Another very useful property for team-based development is to be ''distributed''. It is indeed useful for implementing ''(S-4)'' but also too allow people to work with history without being connected to a centralized server (which is not always possible).

==Some thoughts / Reactions==
;lock-edit-unlock cycle
:is not desirable. We do merging everyday, and we'd like to be able to do the same in Rodin. Lock is too hard a constraint to be useful for us (Systerel).

;granularity
:In an update-edit-merge cycle, granularity is not a problem. In fact, while merging, the whole project must be taken into account, because two changes made in two separate files may have an impact on the semantic of the whole project. I guess, that the smallest element to be considered is the project itself, and consistency is ensure by people doing the right merge (of course, the process of merging may be alleviate by having the team to follow some predefined rules, and the tool to do most of trivial stuff).

;textual merge
:I wonder if textual merge (as it was done until now, because computer program were written as text) is the good solution. It looks like there should be means to greatly automate/guide the merging process by taking the XML structure of the Rodin database into account. You may for example have a look at [http://tdm.berlios.de/3dm/doc/index.html ''3dm'' XML 3-way Merging and Differencing Tool]. Knowing the internal database structure (how are event uniquely identified ? How are proof identified ? How do those informations help to differentiate trivial merges from real conflicts...)

;version control system
:There is nowadays a lot of VCS (SourceSafe, Perforce, CVS, svn, git, mercurial, bazaar, darcs,...). It looks to me that developing a full featured VCS is a several ''man''*''year'' work, and is thus out of the scope of Deploy. As it was proposed by Michael, we should rely on existing VCS, but add plumbing to allow easy merge and preserve database consistency. Ideally we should allow industrialists to use there VCS of choice (even if some of them will certainly be easiest to use with Rodin than others).

;database to text translator
:How will we translate UML elements into text ? Won't the bi-directional translator becomes more and more complex when the database will bear objects other than event and mathematical formulas ?

===proposal draft ===
We are in the process of trying a setup of [http://www.selenic.com/mercurial/wiki/ Mercurial] with [http://tdm.berlios.de/3dm/doc/index.html ''3dm'']. 3dm has known shortcomings (notably when there are conflicts), but it does handle gracefully lot of cases (look at the examples in the source distribution). I hope to keep you informed of problems we will encounter, but we'll eventually at least need:
* a way to resolve conflicts without seeing XML (for model ''and'' proofs).
* a way to review automated merges (because computers do not understand the model semantic, and may do wrong merges)
* a way to review changes between two database snapshots (in order to browse change history, to see diff between working directory and current heads,... )
* ...

===mercurial configuration sample===
<pre><nowiki>
[merge-tools]
xmlmerge.priority = 100
xmlmerge.executable = tdm
xmlmerge.premerge = False
xmlmerge.args = -m $base $local $other $output

[merge-patterns]
**.xml = xmlmerge
**.svg = xmlmerge
**.bum = xmlmerge
**.buc = xmlmerge
**.bpr = xmlmerge
</nowiki></pre>