Re: GERONIMO-1526

[Jason Dillon]

It tracks revisions, so you can automatically merge two branches with out needing to know what revisions to use. This is important, because it is generally easier to resolve conflicts when working on a development branch, by pulling in the latest changes from your source tree and then resolving the changes wrt your local tree.  If you resolve the conflicts when you pull in changes, when you push them back (merge your feature back into the source) then you will have very few (or no) conflicts. http://svk.elixus.org/?MergeFeatures SVK also has some nice features to show you what would conflict before actually applying conflict markers to files, so its easy to see what needs to be handled specially and what can just be automatic. SVK is a good tool to augment anyones existing SVN development environment.  It brings some rich merging and decentralized version control features that can be used with out altering your existing workflow... meaning you don't need IDE support for SVK or have to change your workspaces from SVN to SVK. Though... if IDE's would start to support SVK, then I would probably recommend using it over SVN... but its not there yet, maybe in 6mo or a year?  Dunno. Anyways, I will write a howto with a simple example... and you'll be amazed at how easy it is to merge SVN with SVK. :-) --jason On Aug 24, 2006, at 11:22 AM, Sachin Patel wrote: Agree.  Will create a branch.  Yes if you could post some instructions on svk that would be great.  BTW, what more does svk do compared to svn merge? On Aug 24, 2006, at 2:18 PM, Jason Dillon wrote: I agree, this is what branches are good for. I have been meaning to write a howto doc about how to use svk to merge branches (not to develop, but just to merge).  It works really well for these types of feature branches to manage conflicts and to keep feature branches up to date with the latest from the source tree.  Maybe I'll get to that this weekend. --jason On Aug 24, 2006, at 11:10 AM, Dain Sundstrom wrote: For a change of this size, I suggest you cut a branch as it will let everyone see you work in progress, and I assure it will save you during development as you can rollback bad ideas :) -dain On Aug 24, 2006, at 10:21 AM, Sachin Patel wrote: Please review the following changes, thus far.  Please review the changes carefully to be sure I did not break an existing function. The bulk of this change is: (1) Allows a DeployableModuleImpl class to be set for a single deployment via the DeploymentManager (currently the factory only loads the default, need some advice on how best to load the class for other impls) (2) Introduces DefaultDeployableModule implementation of DeployableModule (2) Changes the use of and passing of JarFile throughout the entire deployment process with DeployableModule. Next I plan to fix all the tests that are now broken, then start plugging in a new Impl of DeployableModule for Eclipse support and see if we need to tweak add/remove methods to the interface as I'm not convinced yet that all the methods currently are sufficient.  This is where the bulk of the work will be so feel free to help out if interested :). <changes.patch> -sachin