Collaborating on binary files (.doc/.odt)
Hi,
In our project we must collaborate on documentation, which is treated like binary file. I've seen on the Team Blog that Jazz was used for Team Concert User Workshop. What are detailed best practices to perform this challenge ? Thanks in advance Sbastien Alcatel-Lucent, R&D Effectivness |
2 answers
Overall you should simply be able to perform regular SCM operations in these binary files.
See https://jazz.net/learn/LearnItem.jsp?href=content/docs/source-control/index.html for an overview of the basic SCM actions. However, we won't have file locking for 1.0, so you'll need to coordinate your edits, for example via chat/mail, to avoid conflictings edits. Now if you happen to edit concurrently, it isn't a problem, you'll get a chance to resolve but without a merge tool, you'll have to pick a version to move foreward. Jean-Michel Lemieux Jazz Source Control Team |
|
We proceed like this, like non-binary files, with communication to avoid conflicts and Jazz always kept us in a stable state.
In the jazz team blog (https://jazz.net/blog/index.php/2008/02/25/the-team-concert-user-workshop-behind-the-scenes/#comments), Jim D'Anjou said that they shared a common workspace, it's a beginning of file locking, isn't it ? As we can only have one change-set per file (unless we 'complete' it). But this file locking comes at the end of file edition, when we save our file. So if I summarize : Is it the best practice to shared a common workspace and if someone wants to edit documentation file, it must start to edit the file and immediately save it ? In order to create change-set and "lock" the file to avoid concurrent edition. Sbastien Etter Alcatel-Lucent, R&D Effectivness |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.