Thanks to the generous people at Atlassian, we now have a much nicer issue tracker and source browser than before. You can check out our Jira instance at http://liquibase.jira.com/browse/CORE and our svn repository at http://liquibase.jira.com/source/browse/CORE.
The issues were bulk moved from the sourceforge tracker, so I will be going over them to recategorize and prioritize them over the next week.
Let me know if you have any questions or have any troubles accessing either tool.
Nathan
Do patches go in this new list, or back on source forge?
(I have a very minor patch, which I left on my work machine, which I will upload tomorrow.)
Nathan,
if you change uuid repository on jira site it will be possible to change current installation with help of
svn switch --relocate
It could preserve current changes.
Now svn reports:
I:\opensource\org\liquibase\trunk>svn switch --relocate https://liquibase.svn.sourceforge.net/svnroot/liquibase/trunk http://liquibase.jira.com/svn/CORE/trunk
svn: The repository at ‘<a href=‘http://liquibase.jira.com/svn/CORE/trunk’’ target=’_blank’>http://liquibase.jira.com/svn/CORE/trunk’ has uuid ‘e6edf6fb-f266-4316-afb4-e53d95876a76’, but the WC has ‘69c58a68-6f28-0410-abe1-eb39e1e2e7fc’
Originally posted by: taranenko
Nathan,if you change uuid repository on jira site it will be possible to change current installation with help of
svn switch --relocate
It could preserve current changes.Now svn reports:
I:\opensource\org\liquibase\trunk>svn switch --relocate https://liquibase.svn.sourceforge.net/svnroot/liquibase/trunk http://liquibase.jira.com/svn/CORE/trunk
svn: The repository at ‘<a href=‘http://liquibase.jira.com/svn/CORE/trunk’’ target=‘_blank’>http://liquibase.jira.com/svn/CORE/trunk’ has uuid ‘e6edf6fb-f266-4316-afb4-e53d95876a76’, but the WC has ‘69c58a68-6f28-0410-abe1-eb39e1e2e7fc’
Good point. I hadn’t used that flag before. Thanks
Originally posted by: catflap
Do patches go in this new list, or back on source forge?(I have a very minor patch, which I left on my work machine, which I will upload tomorrow.)
On this list or in Jira. Jira is probably best, but I did make sure to find a message system that allows attachments.
Hi,
nice to see Liquibase now has Jira (hm, did you notice I like it? 
)
Have the user accounts been migrated? I see my username, but my pw from SourceForge is not working.
Originally posted by: clenz80
Hi,nice to see Liquibase now has Jira (hm, did you notice I like it?
)
Have the user accounts been migrated? I see my username, but my pw from SourceForge is not working.
Atlassian did the transfer over of data from a CSV file I gave them. I think what happened was that they created temporary accounts for the submitters based on the username in the export, but since we don’t have access to your passwords we could not actually migrate accounts.
To create new issues, you’ll have to create a new account on jira. I’m not sure if the username you had on sourceforge will be taken by the created account or not.
Nathan
I just chatted with Atlassian support about the migrated user accounts. The migrated user accounts do block new jira.com registrations using that name. Signing up with a new name will work, but then we lose access to submitted tickets, meaning an admin would have to reassign the tickets to the new user (not optimal). The Atlassian support guy suggested that the admin (I assume that is you, Nathan?) file a support ticket at support.atlassian.com so they can work with the liquibase admin on the orphaned user accounts. Perhaps sourceforge would provide a password hash that jira.com can use for the account passwords.
If sourceforge has a hash of the passwords, they are (hopefully) a one-way hash, so the passwords cannot be recovered. I think the easiest option would be to email me (nathan at voxland.net) your sourceforge account name if you are interested in getting access to the converted account. I can reset the password and send the new password to you.
It does have the security hole of “you can have me send you access to other people’s issues”, but I don’t think that is a problem worth bothering with.
Nathan
Yeah, using hashes makes a big assumption that jira.com already uses one way password hashes. Then it would a matter of seeing if SF already had a compatible hash in their db or could export a compatible hash. Then recovering the actual password would never be needed. I have no idea how they are stored for jira.com accounts.
