On 11/2/05, Shakespeare, Simon (Pensions)
<Simon.Shakespeare@capita.co.uk> wrote:
[snip]
> >
> > Shakespeare, Simon (Pensions) wrote:
> > > Hi - Can anybody explain to why when doing a merge you need
> > to enter the
> > > path in the following manner:
> > >
> > > svn merge --dry-run -r 40:41 svn://ipofserver/phoenix/trunk/gui/mpa
> > > c:/scstest/hiptapp/mpa
> >
> > http://svnbook.red-bean.com/nightly/en/svn.branchmerge.copycha
> > nges.html#svn.branchmerge.copychanges.keyconcept
> >
> > Because this is the syntax basicly :-)
> >
> Would you agree that it's not necessary ?
>
Subversion makes the assumption that automatic merges
should not be trusted to be perfect, therefore there must be
a working copy to which to apply the changes, for human
inspection. Either way you need three urls: from, to and target.
Sometimes from and target are the same, but not always.
> > > I'm trying to merge the commit that resulted in revision 41 - surely
> > > subversion knows what path(s) in the repository that
> > revision 41 related
> > > to so why can't I just enter svn://ipofserver - I can sort
> > of undertand
> > > why I need to enter a destination path for my working copy but am a
> > > confused what happens if revision 41 included several files
> > in different
> > > directories - do you just use the top most path as the path for your
> > > working copy.
> >
Yes the top most path. This allows you to only merge part of a change set.
> > What about:
> > svn merge -r 10:10000 $URL $WD
> > svn applies the changes incrementally, AFAIK, so it needs a
> > space to apply them ($WD)
> >
> > The rule I follow is to merge only whole branches to trunk
> > (or other branches),
> > so the path is known.
> >
> > > The reason I wanted to do this was to try & simplify my
> > merging. When I
> > > do a commit I store that revision against a ticket number
> > in a database
> > > & assumed that it would have been sufficient just to store
> > the revision
> > > number rather than all the paths.
> > Can you clarify that?
>
> To an extent I have to fit in with the structure as it stands at the moment.
> My idea was to have virtually all development on the trunk & store only the
> revision number when it's checked in against a ticket number. From the
> in-house ticket system call svn & merge that revision i.e. N-1:N (which
> could include changes to many programs in different directories - hence my
> reason for wanting to store the version number only) to a test branch when
> ready & ,once it's passed testing, merge the same revision from trunk to a
> live branch + any subsequent revisions that came about as a result of testing
> (which would also be stored against that ticket in our exiting in-house
> ticket system).
> Due to the way we work at present it isn't practical to create lots of
> branches for often 1 line changes. I've thought a lot about this area
> & am still pretty unsure. I worked with Clearcase before in a very well
> managed environment but here the live systems are in a constant state
> of flux & changes are released to it every day ! I know it's not the
> best way but they've worked that way for 15 years without a version
> control system - so I can't change them overnight - little by little I'm afraid.
>
I would suggest not creating a branch for each change, just create a test
working copy, merge the change, then run the tests. If everything is fine
and the merge applied cleanly you can check directly into the production
branch, otherwise a working copy exists for someone to check the merge
and tweak it if necessary.
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 2 16:49:28 2005