While developing a component sometimes we push the changes to the scope (bit export) so we can import and test the changes on other projects, these versions are useless (e.g: 0.0.0-test.1), so we clean them up after finishing working with the component. We'd to have a way of cleaning those test versions using bit remove component_name --ver 1.1.0 -r
I don't fully understand what you're trying to do but I think it will be better if you snap changes instead of tagging a new version and maybe even use a lane. Give it a try and tell me how it works for you.
In Bit, you tag your new versions incrementally. That follows the Semver conventions.
No need to delete older versions; use the newer ones.
But if so you can deprecate it. Deprecating is a nondestructive way to flag an outdated version.
Now, that put aside, you can always open a new developing lane. A lane is like a git branch. It bifurcates from the original path and allows for diverging. Once you are satisfied with the diverge, you can merge it back:
bit lane merge new-feature
Conclusion: you shouldn't delete versions. Create newer ones or depreacate. If what you want is to diverge from the main developing line, use bit lane. You can always merge it back.
Hi currenlty i'm start to use TortoiseSVN, before that i'm using CVS.
Assuming, we have concurrent changes on the same project and each of the changes need to release in different time.
In CVS, when we need to commit a file and we would write down some message in message text box(assume i put in CR00001) and then when we deploying the application, we just get all files that with message equal ='CR0001'. So we've no worry about wrong version to release.
Is there a way for me to do this in TortoiseSVN?
Please help, Thanks.
You can always use TortoiseSVN to update to a specific revision.
For what you're trying to do, though, consider creating a RELEASE branch of the code, then use svnmerge to manage the promotion of specific changesets.
I am using TFS 2010.I have two team project--$project1 and $Project2
They look like-
$project1
dev
rel
$project2
main
Now I want to branch from $project1->dev to $project2, but I am getting error as "TF10169:Unsupported pending change attempted..."
Can anyone let me know is it possible to branch from one team project to another?
Branching from one Team Project to another is fully supported.
If you have a copy of Project1 mapped to your local workspace try doing a Get Latest. For completeness do a Get Specific Version and then select Latest Version to overwrite all locals rather than just Get Latest.
I've seen this error before albeit unrelated to a branch, when deletes have been pending.
Where can I find information on migrating our customized pages from our current install of Bugzilla to the latest, Bugzilla 3.6?
I'm trying to get up to speed on how all of of the pieces come together to make Bugzilla work. I have a working installation of 3.6 in a VHD (we are running on Windows). Next, I just need to figure out how to move our customizations forward.
Thanks!
There are several categories of stuff that you must consider how to move forward:
changes to scripts and modules
If you've been making changes to the code directly, it should be just a matter of merging 3.6 onto your source tree. This can create a number of conflicts, and it can be an exercise in code archaeology to figure out the resolution.
Use this as an opportunity to jump on the code hooks bandwagon so that you have minimal (hopefully no) changes to Mozilla's source, which will make future upgrades a lot easier.
changes to templates
If you've been changing templates in template/en/default, then that's pretty much the same as the case above - you need to merge in Mozilla's changes. If you've been putting customizations into template/en/custom, then you need to evaluate whether you need to make any changes based on corresponding changes to the defaults.
changes to extensions
3.6 introduces some new architecture in the extension system. You'll probably want to dig into this page as much as I have:
http://www.bugzilla.org/docs/3.6/en/html/api/Bugzilla/Extension.html
You'll probably also want to look at the upgrading notes for 3.6:
http://www.bugzilla.org/releases/3.6/release-notes.html#v36_upgrading
Finally, what I didn't notice until I had manually converted an extension, there's a script that will do it for you!
http://www.bugzilla.org/docs/3.6/en/html/api/contrib/extension-convert.html
You may find it helpful to visit #mozwebtools on irc.mozilla.org. That's where all the cool Bugzilla kids hang out! They're happy to chat up customizations to your heart's content.
Can anyone provide some real examples as to how best to keep script files for views, stored procedures and functions in a SVN (or other) repository.
Obviously one solution is to have the script files for all the different components in a directory or more somewhere and simply using TortoiseSVN or the like to keep them in SVN, Then whenever a change is to be made I load the script up in Management Studio etc. I don't really want this.
What I'd really prefer is some kind of batch script that I can run periodically (nightly?) that would export all the stored procedures / views etc that had changed in a given timeframe and then commit them to SVN.
Ideas?
Sounds like you're not wanting to use Revision Control properly, to me.
Obviously one solution is to have the
script files for all the different
components in a directory or more
somewhere and simply using TortoiseSVN
or the like to keep them in SVN
This is what should be done. You would have your local copy you are working on (Developing new, Tweaking old, etc) and as single components/procedures/etc get finished, you would commit them individually until you have to start the process over.
Committing half-done code just because it's been 'X' time since it was last committed is sloppy and guaranteed to cause anyone else using the repository grief.
I find it best to treat Stored Procedures just like any other compilable code: Code lives in the repository, you check it out to make changes and load it in your development tool to compile or deploy the code.
You can create a batch file and schedule it:
delete the contents of your scripts directory
using something like ExportSQLScript to export all objects to script/scripts
svn commit
Please note: That although you'll have the objects under source control, you'll not have the data or it's progression (is that a renamed field, or 1 new field and 1 deleted?).
This approach is fine for maintaining change history. But, of course, you should never be automatically committing to the "production build" (unless you like broken builds).
Although you didn't ask for it: This approach also won't produce a set of scripts that will upgrade a current DB. You'll only have initial creation scripts. Recording data progression and creation upgrade scripts is beyond basic source control systems.
I'd recommend Redgate SQL Compare for this - it allows you to compare database versions and generate change scripts - it's also fairly easily scriptable.
Based on your expanded question, you really want to use DDL triggers. Check out this article that details how to create a changelog system for your database.
Not sure on your price range, however DB Ghost could be an option for you.
I don't work for this company (or own the product) but in my researching of the same issue, this product looked quite promising.
I should've been a little more descriptive. The database in question is for an internal ERP system and thus we don't have many versions of our database, just Production/Testing/Development. When we've done a change request, some new fancy feature or something, we simply execute a script or series of scripts to update the procedures in question on the Testing database, if that is all good, then we do the same to Production.
So I'm not really after a full schema script per se, just something that can keep track of the various edits to the stored procedures over time. For example, PROCESS_INVOICE does stuff. It gets updated in some minor way in March. Some time later in say May it is discovered that in a rare case customers get double invoiced (or some other crazy corner case). I'd like to be able to see what has happened over time to this procedure. Currently the way the development environment is setup here I don't have that, which I'm trying to change.
I can recommend DBPro which is part of Visual Studio Team Edition. Have been using it for a few months for storing all parts of the database in Team Foundation Server as well as for deployment and database compares, etc.
Of course, as someone else mentioned, it does depend on your environment and price range.
I wrote a utility for dumping all of the relevant parts of my db into a directory structure that I use SVN on. I never got around to trying to incorporate it into the Manager but, if you're interested, it's here: http://www.reluctantdba.com/dbas-and-programmers/sqltools/svnforsql2005.aspx
It's free and, since I regularly run it, you know any bugs get fixed quickly.
You can always try integrating SourceSafe with SQL Server. Here's a quick start : link . To work with it you've got to have Managment Studio Developers Edition.