Differences
This shows you the differences between two versions of the page.
|
developers:spec:vcs_revamp [2012/07/05 16:09] friedelwolff |
developers:spec:vcs_revamp [2012/07/10 15:40] (current) friedelwolff |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== VCS Revamp ====== | ====== VCS Revamp ====== | ||
| - | Bug 2255 arises wider discussion about how we should be dealing with | + | [[bug>2255]] arises wider discussion about how we should be dealing with |
| VCS systems. | VCS systems. | ||
| Line 51: | Line 51: | ||
| * Correct updating in case of VCSs like git. | * Correct updating in case of VCSs like git. | ||
| - | Should we be merging as often or even automatically? | + | Should we be merging as often or even automatically? (db) since we see VC as king it would make sense to updating continuously either through a regular check or an API that responds to a post commit hook. |
| ==== New files added in Pootle ==== | ==== New files added in Pootle ==== | ||
| Line 81: | Line 81: | ||
| ==== Files removed from VCS ==== | ==== Files removed from VCS ==== | ||
| - | New files added in VCS should reflect in Pootle at some stage (if the language is added). | + | Files removed from VCS should be removed from Pootle at some stage. |
| **Status quo**: Someone will have to remove from VCS, and someone with appropriate privileges need to remove it from Pootle as well. | **Status quo**: Someone will have to remove from VCS, and someone with appropriate privileges need to remove it from Pootle as well. | ||
| **Wanted**: When updating the project/translation project, any files found to be removed from VCS should automatically be removed in Pootle. We need to take care not to remove _other_ files (like pootle-terminology). | **Wanted**: When updating the project/translation project, any files found to be removed from VCS should automatically be removed in Pootle. We need to take care not to remove _other_ files (like pootle-terminology). | ||
| + | |||
| + | (db) our concern might be loss of TM through mistakes, so we might want to retire such strings in the db so that they can form part of any local TM or be used again if the strings return. | ||
| ==== Code changes in VCS ==== | ==== Code changes in VCS ==== | ||
| Line 96: | Line 98: | ||
| + | ==== See VCS status ==== | ||
| + | A user would like to see what the status is of their file(s) with regard to the VCS system. This would be something similar to the output of "git status" or similar. For example, this would way that there are changes that are not checked in, or that there are changes in the VCS that are not yet reflected in Pootle (need to update). | ||
| + | |||
| + | **Status quo**: We don't provide any help here | ||
| + | |||
| + | **Wanted**: Some simple (graphical?) representation would be great. | ||
| ===== Advantages and disadvantages ===== | ===== Advantages and disadvantages ===== | ||
| Line 166: | Line 174: | ||
| * Store/use repositories not as part of the podirectory | * Store/use repositories not as part of the podirectory | ||
| * Code / documentation to handle upgrade to the new system | * Code / documentation to handle upgrade to the new system | ||
| + | * Hooks also need to be adapted to work with names relative to the podirectory/checkout directory instead of absolute paths. We need to document this as well. | ||
| * On commit and update, we need to handle the files living in two locations. | * On commit and update, we need to handle the files living in two locations. | ||
| Line 175: | Line 184: | ||
| straightforward to change Pootle's code to work in that way. Plus, we would need to implement a separate command-line client that communicates with the Pootle server. It is a lot of work. | straightforward to change Pootle's code to work in that way. Plus, we would need to implement a separate command-line client that communicates with the Pootle server. It is a lot of work. | ||
| - | Taking all of this into account, probably the best way to go is to try to fix bug 2255 without extensively changing the current architecture. Afterwards, early in the next release cycle, a change to the whole architecture would make more sense, getting the advantages of the Transifex's approach in the next release. | + | Taking all of this into account, probably the best way to go is to try to fix bug 2255 without extensively changing the current architecture. Afterwards, early in the next release cycle, a change to the whole architecture would make more sense, getting the advantages of the chosen approach in the next release. |
Page Tools
developers/spec/vcs_revamp.1341504576.txt.gz · Last modified: 2012/07/05 16:09 by friedelwolff ·
