On Saturday 31 March 2007 08:45, Andrew Close wrote:
> On 3/31/07, Kenneth Porter <shiva@sewingwitch.com> wrote:
> > --On Wednesday, March 14, 2007 5:46 PM -0500 Andrew Close
> >
> > <aclose@gmail.com> wrote:
> > > what we've attempted to do is create a branch in SVN off of the
> > > Project A codebase. checkout branch A' to a local workspace.
> > > overlay the A' workspace with the source from the VSS
> > > repository and add/commit so that A' now matches what came from
> > > VSS. we then attempt to merge branch A' with A, but the merge
> > > appears to just overwrite the code in A with A' even though
> > > there should be conflicts that need resolving.
> >
> > What you want is a "vendor branch":
> >
> > <http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.htm
> >l>
> >
> > Consider your VSS project to be your vendor. A checkout from VSS
> > represents a "vendor drop".
> >
> > I used this with one of my customers before they switched to
> > Subversion. (At that point I changed from a VSS checkout to a
> > Subversion export to get a snapshot of their current
> > development.)
>
> thanks Kenneth, i'll read that section of the redbook.
> in moving to SVN we'll be changing our directory structure so it
> won't really be a one to one correlation between branches. we'll
> have to do a bit of massaging, but that isn't a big deal.
> i was more concerned with the merge process, for which i still
> haven't found a good solution. right now our VSS merges between
> branches are painfully manual and involve several days of merging
> to a common branch. i was really hoping to have a more automated
> solution for the merge into SVN. but if we have to manually merge
> for the time being we'll deal with it. hopefully once we have
> everything in one SVN repository we'll be able to make use of the
> branching and merging features SVN provides and cut down on some of
> that manual work.
I'm afraid that you are complicating it more than you need. Vendor
branches are all about tracking changes in your SVN repository which
were applied to a different system, such as VSS. Yes, the purpose is
to successfully 'merge' the VSS changes with the SVN changes (if
any). Is that not what you are trying to do? Are you talking about a
different kind of merge, I'm about your expression, "merge into SVN",
as if you are trying to merge without first importing.
BTW an important part of vendor branches is using "svn_load_dirs.pl",
which performs the "importing" of further vendor releases after the
first one is imported. Read up on that, then maybe we could help
further.
Of course once you have the vendor branch successfully tracking
changes from VSS, the `svn merge` is yet another subject, and very
nice once understood.
Hope you also know about this recently posted
http://www.neilstuff.com/subversion/svn-tutorial-for-vss-users.htm
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 5 22:10:37 2007