Thanks Kalin....
> -----Original Message-----
> From: Kalin KOZHUHAROV [mailto:kalin@thinrope.net]
> Sent: 01 November 2005 16:21
> To: Shakespeare, Simon (Pensions)
> Cc: users@subversion.tigris.org
> Subject: Re: Merging - why do I need a path ?
>
>
> PLEASE do consider NOT posting HTML to any mailing list.
OK - Point taken.
>
> 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 ?
> > 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.
>
> 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.
>
> > Thanks - Can you include me in the reply as I not a member
> of the users
> > mailing group - well I was but I got swamped with emails & my boss
> > wasn't happy !
> Then how do you stay current to the technology?
> This is a very informative ML, so talk to your boss, about
> that. I did it and it worked.
You're right of course & the answer to this is that we don't !
>
> Kalin.
> --
> |[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
> +-> http://ThinRope.net/ <-+
> |[ ______________________ ]|
>
> This email has been scanned for all viruses by the
> MessageLabs SkyScan service.
>
**********************************************************************************
This email and any files transmitted with it are confidential, and may be subject to legal privilege, and are intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error or think you may have done so, you may not peruse, use, disseminate, distribute or copy this message. Please notify the sender immediately and delete the original e-mail from your system.
Computer viruses can be transmitted by e-mail. Recipients should check this e-mail for the presence of viruses. The Capita Group and its subsidiaries accept no liability for any damage caused by any virus transmitted by this e-mail.
***********************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 2 11:00:53 2005