Piston 2.0 Progress: Piston can import Subversion repositories into Subversion working copies
Well, it’s working. Piston 2.0 (aka 1.9.0 in Piston’s GitHub repository) can import from a Subversion repository, into a Subversion working copy. And it’s mostly saving the same information as it was previously, in the same way.
But, I received a suggestion/comment from Faisal:
so i’m wondering if it wouldn’t make sense to have the per-vcs metadata formats replaced with something like config/piston.yml, read by piston. the main advantage to doing so would be easier conversion between format types, especially in cases where one type is checking out from another (e.g. svk or git-svn against an svn back-end).
Faisal N Jawdat in a private E-Mail conversation
Actually, this is not a bad idea. Using this method, a Subversion project, imported in a Git repository, would still be able to use Piston to update the vendor branch. The more the information is accessible, the better it will be.
This means Piston needs to provide an upgrade path. I shall do like Subversion, which silently upgrades the working copy when necessary. And to be on the safe side, I shall also include a format in the piston metadata to enable future upgrades with easier handling.
Recapping, Pistonized directories will now have a new, hidden, file:
1 2 3 4 |
$ ls -A1 vendor/rails .piston-metadata.yml activerecord/ ... |
And the .piston-metadata.yml file would contain something like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
$ cat vendor/rails/.piston-metadata.yml # What data can Piston expect from this file ? format: 1 # Which repository handler must we use ? repository: svn # Properties that the handler wanted us to save handler-metadata: # Same as piston:remote-revision remote-revision: 9025 # Same as piston:root svn-root: http://dev.rubyonrails.org/svn/rails/trunk # Same as piston:uuid svn-uuid: 5ecf4fe2-1ee6-0310-87b1-e25e094e27de |
If you were aware of how Piston was storing properties, you might not that the piston:local-revision property is gone. Instead of hard-coding which revision we need to import, I’ll instead use the last changed date/time. It’s less precise, but makes interoperability with different repository handlers much easier. No need to map between revision 8920 of Subversion to Git commits.
That looks promising, no ?
Next step ? Implementing the Git backend. After that, it’s testing Svn+Git, Git+Svn, Git+Git and Svn+Svn. Hurray!
Leave a Reply