pre-lock.bat Failed in Repo browser
Hi Experts! Below is the "pre-lock.bat " Script Only User who lock the file can unlock the file. Other users are forbidden to Unlock file. @echo off :: Set all parameters set repository=%1 set repopath=%2 set user=%3 :: Set path to svnlook set svnlook=%VISUALSVN_SERVER%bin\svnlook.exe :: First check that the lock exists already. :: In that case svnlook prints the lock description. "%svnlook%" lock "%repository%" %repopath% | findstr /B /L "UUID Token:" > NUL 2>&1 :: If the lock does not exist, allow locking if ERRORLEVEL 1 exit 0 :: Now check the lock's owner "%svnlook%" lock "%repository%" %repopath% | findstr /C:"Owner: %user%" > NUL 2>&1 :: If the person locking matches the lock's owner, allow locking if %ERRORLEVEL% EQU 0 exit 0 :: Otherwise, return failure echo "Error: %repopath% is locked already." >&2 exit 1 Issue/Problem!! This scenario failed in Repo Browser. Any one can Unlock File/Folder through Repo Browser. Please advice me accordingly. Thanks DISCLAIMER: This e-mail and any file transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended recipient, you are hereby advised that any dissemination, distribution or copy of this email or its attachments is strictly prohibited. If you have received this email in error, please immediately notify us by return email and destroy this email message and its attachments. This communication may contain forward-looking statements relating to the development of NetSol Technologies' products and services and future operations. The words "believe," "expect," "anticipate," "intend," variations of such words, and similar expressions, identify forward looking statements, but their absence does not mean that the statement is not forward-looking. Views and opinions contained herein are those of the author of this email and do not necessarily represent those of NetSol Technologies. Statements contained herein are not guarantees of future performance and are subject to certain risks, uncertainties and assumptions that are difficult to predict. The company will not undertake to update any statements contained herein. WARNING: The recipient should check this email and any attachment for the presence of viruses. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company does not accept responsibility for any loss or damage arising from the use of this email or attachment. Note: Please consider the environment before printing this e-mail.
Re: pre-lock.bat Failed in Repo browser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-03-08 06:51, Waseem Bokhari wrote: > Hi Experts! >Below is the "pre-lock.bat " Script > > Only User who lock the file can unlock the file. Other users are > forbidden to Unlock file. [...] > *Issue/Problem!!* > > This scenario failed in Repo Browser. Any one can Unlock File/Folder > through Repo Browser. > > Please advice me accordingly. Waseem, that's too little information to give advice. Tell us about your repository and client setup. Wild guess: are you perhaps using the file:// access method when browsing the repository? Hook scripts are run by the Subversion server process. Using the file:// access method effectively disables them. http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-repository.html#tsvn-repository-create http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-repository-hooks.html - -- Michael Diers, elego Software Solutions GmbH, http://www.elego.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk11+T8ACgkQcEKlWnqVgz3cWgCgrGAuUSuFjKjf0U/+fM2/kZoR gucAnRgp1IFwcqHsvgtkyCH+789pG18z =GSif -END PGP SIGNATURE-
RE: pre-lock.bat Failed in Repo browser
We are working in Windows Environment. Visual SVN on Server Side as administration Tool and Tortoise SVN of Client. We are using HTTPS as well. Repository URL looks as :- https://ServerMachine.Domain.com:8443/svn/MyRepository Thanks in advance Muchas gracias! Waseem Bokhari -Original Message- From: Michael Diers [mailto:mdi...@elego.de] Sent: Tuesday, March 08, 2011 2:39 PM To: Waseem Bokhari Cc: users@subversion.apache.org Subject: Re: pre-lock.bat Failed in Repo browser -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-03-08 06:51, Waseem Bokhari wrote: > Hi Experts! >Below is the "pre-lock.bat " Script > > Only User who lock the file can unlock the file. Other users are > forbidden to Unlock file. [...] > *Issue/Problem!!* > > This scenario failed in Repo Browser. Any one can Unlock File/Folder > through Repo Browser. > > Please advice me accordingly. Waseem, that's too little information to give advice. Tell us about your repository and client setup. Wild guess: are you perhaps using the file:// access method when browsing the repository? Hook scripts are run by the Subversion server process. Using the file:// access method effectively disables them. http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-repository.html#tsvn-repository-create http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-repository-hooks.html - -- Michael Diers, elego Software Solutions GmbH, http://www.elego.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk11+T8ACgkQcEKlWnqVgz3cWgCgrGAuUSuFjKjf0U/+fM2/kZoR gucAnRgp1IFwcqHsvgtkyCH+789pG18z =GSif -END PGP SIGNATURE- DISCLAIMER: This e-mail and any file transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended recipient, you are hereby advised that any dissemination, distribution or copy of this email or its attachments is strictly prohibited. If you have received this email in error, please immediately notify us by return email and destroy this email message and its attachments. This communication may contain forward-looking statements relating to the development of NetSol Technologies' products and services and future operations. The words "believe," "expect," "anticipate," "intend," variations of such words, and similar expressions, identify forward looking statements, but their absence does not mean that the statement is not forward-looking. Views and opinions contained herein are those of the author of this email and do not necessarily represent those of NetSol Technologies. Statements contained herein are not guarantees of future performance and are subject to certain risks, uncertainties and assumptions that are difficult to predict. The company will not undertake to update any statements contained herein. WARNING: The recipient should check this email and any attachment for the presence of viruses. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company does not accept responsibility for any loss or damage arising from the use of this email or attachment. Note: Please consider the environment before printing this e-mail.
RE: pre-lock.bat Failed in Repo browser
I don't think %VISUALSVN_SERVER% is set in your lock script. Subversion explicitly clears most environment variables before calling hook scripts. Most likely your script can't find svnlook.exe Bert From: Waseem Bokhari [mailto:waseem.bokh...@netsoltech.com] Sent: dinsdag 8 maart 2011 7:52 To: users@subversion.apache.org Subject: pre-lock.bat Failed in Repo browser Hi Experts! Below is the "pre-lock.bat " Script Only User who lock the file can unlock the file. Other users are forbidden to Unlock file. @echo off :: Set all parameters set repository=%1 set repopath=%2 set user=%3 :: Set path to svnlook set svnlook=%VISUALSVN_SERVER%bin\svnlook.exe :: First check that the lock exists already. :: In that case svnlook prints the lock description. "%svnlook%" lock "%repository%" %repopath% | findstr /B /L "UUID Token:" > NUL 2>&1 :: If the lock does not exist, allow locking if ERRORLEVEL 1 exit 0 :: Now check the lock's owner "%svnlook%" lock "%repository%" %repopath% | findstr /C:"Owner: %user%" > NUL 2>&1 :: If the person locking matches the lock's owner, allow locking if %ERRORLEVEL% EQU 0 exit 0 :: Otherwise, return failure echo "Error: %repopath% is locked already." >&2 exit 1 Issue/Problem!! This scenario failed in Repo Browser. Any one can Unlock File/Folder through Repo Browser. Please advice me accordingly. Thanks DISCLAIMER: This e-mail and any file transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended recipient, you are hereby advised that any dissemination, distribution or copy of this email or its attachments is strictly prohibited. If you have received this email in error, please immediately notify us by return email and destroy this email message and its attachments. This communication may contain forward-looking statements relating to the development of NetSol Technologies' products and services and future operations. The words "believe," "expect," "anticipate," "intend," variations of such words, and similar expressions, identify forward looking statements, but their absence does not mean that the statement is not forward-looking. Views and opinions contained herein are those of the author of this email and do not necessarily represent those of NetSol Technologies. Statements contained herein are not guarantees of future performance and are subject to certain risks, uncertainties and assumptions that are difficult to predict. The company will not undertake to update any statements contained herein. WARNING: The recipient should check this email and any attachment for the presence of viruses. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company does not accept responsibility for any loss or damage arising from the use of this email or attachment. Note: Please consider the environment before printing this e-mail.
RE: pre-lock.bat Failed in Repo browser
I don't think %VISUALSVN_SERVER% is set in your lock script. What is meant by this? How can I found "svnlook.exe" ?? Can you please re-edit this script for me. Thanks in advance From: Bert Huijben [mailto:b...@qqmail.nl] Sent: Tuesday, March 08, 2011 7:04 PM To: 'Waseem Bokhari'; users@subversion.apache.org Subject: RE: pre-lock.bat Failed in Repo browser I don't think %VISUALSVN_SERVER% is set in your lock script. Subversion explicitly clears most environment variables before calling hook scripts. Most likely your script can't find svnlook.exe Bert From: Waseem Bokhari [mailto:waseem.bokh...@netsoltech.com] Sent: dinsdag 8 maart 2011 7:52 To: users@subversion.apache.org Subject: pre-lock.bat Failed in Repo browser Hi Experts! Below is the "pre-lock.bat " Script Only User who lock the file can unlock the file. Other users are forbidden to Unlock file. @echo off :: Set all parameters set repository=%1 set repopath=%2 set user=%3 :: Set path to svnlook set svnlook=%VISUALSVN_SERVER%bin\svnlook.exe :: First check that the lock exists already. :: In that case svnlook prints the lock description. "%svnlook%" lock "%repository%" %repopath% | findstr /B /L "UUID Token:" > NUL 2>&1 :: If the lock does not exist, allow locking if ERRORLEVEL 1 exit 0 :: Now check the lock's owner "%svnlook%" lock "%repository%" %repopath% | findstr /C:"Owner: %user%" > NUL 2>&1 :: If the person locking matches the lock's owner, allow locking if %ERRORLEVEL% EQU 0 exit 0 :: Otherwise, return failure echo "Error: %repopath% is locked already." >&2 exit 1 Issue/Problem!! This scenario failed in Repo Browser. Any one can Unlock File/Folder through Repo Browser. Please advice me accordingly. Thanks DISCLAIMER: This e-mail and any file transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended recipient, you are hereby advised that any dissemination, distribution or copy of this email or its attachments is strictly prohibited. If you have received this email in error, please immediately notify us by return email and destroy this email message and its attachments. This communication may contain forward-looking statements relating to the development of NetSol Technologies' products and services and future operations. The words "believe," "expect," "anticipate," "intend," variations of such words, and similar expressions, identify forward looking statements, but their absence does not mean that the statement is not forward-looking. Views and opinions contained herein are those of the author of this email and do not necessarily represent those of NetSol Technologies. Statements contained herein are not guarantees of future performance and are subject to certain risks, uncertainties and assumptions that are difficult to predict. The company will not undertake to update any statements contained herein. WARNING: The recipient should check this email and any attachment for the presence of viruses. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company does not accept responsibility for any loss or damage arising from the use of this email or attachment. Note: Please consider the environment before printing this e-mail. DISCLAIMER: This e-mail and any file transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended recipient, you are hereby advised that any dissemination, distribution or copy of this email or its attachments is strictly prohibited. If you have received this email in error, please immediately notify us by return email and destroy this email message and its attachments. This communication may contain forward-looking statements relating to the development of NetSol Technologies' products and services and future operations. The words "believe," "expect," "anticipate," "intend," variations of such words, and similar expressions, identify forward looking statements, but their absence does not mean that the statement is not forward-looking. Views and opinions contained herein are those of the author of this email and do not necessarily represent those of NetSol Technologies. Statements contained herein are not guarantees of future performance and are subject to certain risks, uncertainties and assumptions that are difficult to predict. The company will not undertake to update any statements contained herein. WARNING: The recipient should check this email and any attachment for the presence of viruses. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company does not accept responsibility for any loss or damage arising from the use of this email or attachment. Note: Please consider the environment before printing this e-mail.
Re: pre-lock.bat Failed in Repo browser
On 3/8/2011 6:24 AM, Waseem Bokhari wrote: I don't think %VISUALSVN_SERVER% is set in your lock script. What is meant by this? How can I found "svnlook.exe"?? Can you please re-edit this script for me. Thanks in advance What he means is that %VISUALSVN_SERVER% will not have a value when running from a hook script. From a Command Prompt window, type: echo %VISUALSVN_SERVER% Then substitute the returned value into your script. If you run this echo command in the hook script during a commit operation, it will not print anything. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA
RE: pre-lock.bat Failed in Repo browser
From: Waseem Bokhari [mailto:waseem.bokh...@netsoltech.com] Sent: 08 March 2011 14:24 To: 'Bert Huijben'; users@subversion.apache.org Subject: RE: pre-lock.bat Failed in Repo browser I don't think %VISUALSVN_SERVER% is set in your lock script. What is meant by this? The hook scripts are deliberately run with as few environment variables set as possible (same as with cron on Unix) to mitigate security risks. So if you knnow exactly where svnlook.exe is on your server machine, you should set this explicitly: VISUALSVN_SERVER="C:\Program FIles\Virtual SVN" or whatever, right at the start. How can I found "svnlook.exe" ?? Can you please re-edit this script for me. Thanks in advance From: Bert Huijben [mailto:b...@qqmail.nl] Sent: Tuesday, March 08, 2011 7:04 PM To: 'Waseem Bokhari'; users@subversion.apache.org Subject: RE: pre-lock.bat Failed in Repo browser I don't think %VISUALSVN_SERVER% is set in your lock script. Subversion explicitly clears most environment variables before calling hook scripts. Most likely your script can't find svnlook.exe Bert From: Waseem Bokhari [mailto:waseem.bokh...@netsoltech.com] Sent: dinsdag 8 maart 2011 7:52 To: users@subversion.apache.org Subject: pre-lock.bat Failed in Repo browser Hi Experts! Below is the "pre-lock.bat " Script Only User who lock the file can unlock the file. Other users are forbidden to Unlock file. @echo off :: Set all parameters set repository=%1 set repopath=%2 set user=%3 :: Set path to svnlook set svnlook=%VISUALSVN_SERVER%bin\svnlook.exe :: First check that the lock exists already. :: In that case svnlook prints the lock description. "%svnlook%" lock "%repository%" %repopath% | findstr /B /L "UUID Token:" > NUL 2>&1 :: If the lock does not exist, allow locking if ERRORLEVEL 1 exit 0 :: Now check the lock's owner "%svnlook%" lock "%repository%" %repopath% | findstr /C:"Owner: %user%" > NUL 2>&1 :: If the person locking matches the lock's owner, allow locking if %ERRORLEVEL% EQU 0 exit 0 :: Otherwise, return failure echo "Error: %repopath% is locked already." >&2 exit 1 Issue/Problem!! This scenario failed in Repo Browser. Any one can Unlock File/Folder through Repo Browser. Please advice me accordingly. Thanks DISCLAIMER: This e-mail and any file transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended recipient, you are hereby advised that any dissemination, distribution or copy of this email or its attachments is strictly prohibited. If you have received this email in error, please immediately notify us by return email and destroy this email message and its attachments. This communication may contain forward-looking statements relating to the development of NetSol Technologies' products and services and future operations. The words "believe," "expect," "anticipate," "intend," variations of such words, and similar expressions, identify forward looking statements, but their absence does not mean that the statement is not forward-looking. Views and opinions contained herein are those of the author of this email and do not necessarily represent those of NetSol Technologies. Statements contained herein are not guarantees of future performance and are subject to certain risks, uncertainties and assumptions that are difficult to predict. The company will not undertake to update any statements contained herein. WARNING: The recipient should check this email and any attachment for the presence of viruses. Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company does not accept responsibility for any loss or damage arising from the use of this email or attachment. Note: Please consider the environment before printing this e-mail. DISCLAIMER: This e-mail and any file transmitted with it are confidential and intended solely for the use of the addressee. If you are not the intended recipient, you are hereby advised that any dissemination, distribution or copy of this email or its attachments is strictly prohibited. If you have received this email in error, please immediately notify us by return email and de
cannot roll back a change
It appears that I cannot roll back (back out, strip) a certain change. Specifically, a directory (with all its contents) has been removed and then (in a separate commit) replaced with a symbolic link (complete with the svn:special property). I googled that and it appears that the official method is "svn merge -rB:A" where A+1 is the change which removed the directory and B=A+2 is the change which added the symlink. Alas, the above command does nothing. I manually removed the symlink and re-added the directory and files in it, but it looks I lost their history (this would not have been the case with cvs!). So, what is the right way to roll back such a change? Is there a way to save the history of the files in the restored directory? Thanks! Linux 2.6.18-164.el5 CentOS release 5.3 (Final) svn, version 1.6.6 (r40053) compiled Oct 22 2009, 08:33:25 -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) X http://mideasttruth.com http://truepeace.org http://honestreporting.com http://iris.org.il http://www.PetitionOnline.com/tap12009/ As a computer, I find your faith in technology amusing.
dumping part of a repository with moved files
Hi, I need to migrate a top level project, which includes files moved from another top level project, to a new repository. I've migrated part of a repository before with no issues with something like: svnadmin dump e:\foo\svn_repo | svndumpfilter include --renumber-revs --drop-empty-revs project_name > e:\project_name.dump But I'm not sure what the behaviour will be for files moved from another project. Will the history be retained beyond the point files moved to project_name? Will it just reference a non-existent project in the new repository? Has anybody got experience of this? Will I need to dump the old location too? Or even each file individually and hack the dump file to never be in the old project? Thanks Chris *bypass*
Understanding merging
I work with a very senior colleague who has never always resisted version control and would much rather do without it, but he is forced to go along and I am the whipping boy whenever something goes wrong. He poses a general but simple question that I find myself unable to give a simple answer to. I am rephrasing it slightly but it bothers me that I don't know the simple answer. If I found myself in this situation I would tweak until it was as desired, but my persnickety colleague is not satisfied with such answers and for once, I don't blame him. Given two branches off a trunk that were taken at different times, if the first is merged back to the trunk and then the second, how may the second be merged back into the trunk so as not to override changes from the first merge, assuming that both change sets are desired to be in the trunk at the end?
Understanding merging
I work with a very senior colleague who has never always resisted version control and would much rather do without it, but he is forced to go along and I am the whipping boy whenever something goes wrong. He poses a general but simple question that I find myself unable to give a simple answer to. I am rephrasing it slightly but it bothers me that I don't know the simple answer. If I found myself in this situation I would tweak until it was as desired, but my persnickety colleague is not satisfied with such answers and for once, I don't blame him. Given two branches off a trunk that were taken at different times, if the first is merged back to the trunk and then the second, how may the second be merged back into the trunk so as not to override changes from the first merge, assuming that both change sets are desired to be in the trunk at the end? smime.p7s Description: S/MIME Cryptographic Signature
Re: Understanding merging
Steve, The way we handle this situation, which happens a lot on our svn repository, is as follows: When we merge a branch into trunk, if there are other branches which were originally merged from trunk we next merge trunk into each of the other branches so that the other branches will be ready to merge back into trunk without any conflicts. Thanks, Tim On 08/03/2011 18:30, "Steve Cohen" wrote: >I work with a very senior colleague who has never always resisted >version control and would much rather do without it, but he is forced to >go along and I am the whipping boy whenever something goes wrong. > >He poses a general but simple question that I find myself unable to give >a simple answer to. I am rephrasing it slightly but it bothers me that >I don't know the simple answer. If I found myself in this situation I >would tweak until it was as desired, but my persnickety colleague is not >satisfied with such answers and for once, I don't blame him. > >Given two branches off a trunk that were taken at different times, if >the first is merged back to the trunk and then the second, how may the >second be merged back into the trunk so as not to override changes from >the first merge, assuming that both change sets are desired to be in the >trunk at the end? >
Re: Understanding merging
On Tue, Mar 08, 2011 at 12:30:46PM -0600, Steve Cohen wrote: > I work with a very senior colleague who has never always resisted > version control and would much rather do without it, but he is > forced to go along and I am the whipping boy whenever something goes > wrong. > > He poses a general but simple question that I find myself unable to > give a simple answer to. I am rephrasing it slightly but it bothers > me that I don't know the simple answer. If I found myself in this > situation I would tweak until it was as desired, but my persnickety > colleague is not satisfied with such answers and for once, I don't > blame him. > > Given two branches off a trunk that were taken at different times, > if the first is merged back to the trunk and then the second, how > may the second be merged back into the trunk so as not to override > changes from the first merge, assuming that both change sets are > desired to be in the trunk at the end? Nothing will ever be "overridden". The reintegrate merge attempts to apply the delta between the trunk and the branch and to a working copy of the merge target (i.e. the trunk). If conflicting changes exist in the merge target, they will be marked as such. It's up to the person doing the merge to resolve these conflicts. Thus, Subversion isn't making decisions about changes overriding one another. It simply provides users with tooling to carry out their own decisions. I think the other reply you got, which recommends syncing all branches to the trunk as soon as a big merge into the trunk occurred, is good advice. BTW, there is a new help text for "svn merge", which will be released in 1.7. It is also valid for 1.6. Maybe it will help your colleague as a reference (but it doesn't replace study of the merging chapters in the Subversion book at svnbook.org!). I'm quoting it below. -- merge: Apply the differences between two sources to a working copy path. usage: 1. merge [-c M[,N...] | -r N:M ...] SOURCE[@REV] [TARGET_WCPATH] 2. merge --reintegrate SOURCE[@REV] [TARGET_WCPATH] 3. merge SOURCE1[@N] SOURCE2[@M] [TARGET_WCPATH] 1. The first form is called a "sync", or "cherry-pick", merge: svn merge [-c M[,N...] | -r N:M ...] SOURCE[@REV] [TARGET_WCPATH] A sync merge is used to merge into a branch any unmerged changes made on its immediate ancestor branch. A cherry-picking merge is used to merge specific revisions from one branch to another. SOURCE is usually a URL. The source of a cherry-picking merge can also be a working copy path, in which case the corresponding URL of the path is used. If REV is specified, it is used as the peg revision for SOURCE, i.e. SOURCE is looked up in the repository at revision REV. If REV is not specified, the HEAD revision is assumed. TARGET_WCPATH is a working copy of the branch the changes will be applied to. '-r N:M' specifies a revision range to be merged. The difference between SOURCE@REV as it existed at revision N, and SOURCE@REV at it existed at revision M, is merged into TARGET_WCPATH. If no revision range is specified, the default range of 0:REV is used. If mergeinfo within TARGET_WCPATH indicates that revisions within the range were already merged, changes made in those revisions are not merged again. If needed, the range is broken into multiple sub-ranges, and each sub-range is merged separately. If N is greater than M, the range is a "reverse range". A reverse range can be used to undo changes made to SOURCE between revisions N and M. '-c M' is equivalent to the range '-r :M'. '-c -M' does the reverse: '-r M:'. Multiple '-c' and/or '-r' options may be specified and mixing of forward and reverse ranges is allowed. - Sync Merge Example - A feature is being developed on a branch called "feature". The feature branch is regularly synced with trunk to keep up with changes made there. feature +o- / ^ / / / .../ trunk --+L--R-- r100 r200 In the above diagram, L marks the "left" side of the merge (trunk@100), and R marks the "right" side of the merge (trunk@200). The difference between the left and right side is merged into the target. To perform the merge, check out a working copy of the feature branch and run the following command in the top-level directory of the working copy: svn merge ^/trunk The default revision range is -r0:HEAD, so any unmerged changes will be merged. - Cherry-picking Merge Example - A bug has been fixed on trunk on revision 50. This fix needs to be merged from the
RE: Understanding merging
-Original Message-
From: Steve Cohen [mailto:stevec...@comcast.net]
Sent: Tuesday, March 08, 2011 12:20 PM
To: users@subversion.apache.org
Subject: Understanding merging
> I work with a very senior colleague who has never always resisted version
> control and would much rather do without it, but he is forced to go along and
> I am the whipping boy whenever something goes wrong.
> He poses a general but simple question that I find myself unable to give a
> simple answer to. I am rephrasing it slightly but it bothers me that I don't
> know the simple answer. If I found myself in this situation I would tweak
> until it was as desired, but my persnickety colleague is not satisfied with
> such answers and for once, I don't blame him.
> Given two branches off a trunk that were taken at different times, if the
> first is merged back to the trunk and then the second, how may the second be
> merged back into the trunk so as not to override changes from the first
> merge, assuming that both change sets are desired to be in the trunk at the
> end?
Do the branches receive updates from trunk or not?
If the answer is yes, then before merging a branch back to trunk, one final
update from trunk to the branch must be performed. The branch is now
up-to-date with trunk, and (ideally) the changes on the branch should be
retested to make sure everything works. When ready, the branch is merged using
the "reintegrate" option back to the trunk. Using "reintegrate", the
differences between the branch and the trunk are computed and the changes
applied to the trunk.
If the answer is no, then when the changes on the branch are ready to be merged
back to the trunk the "reintegrate" option must NOT be used. Without
"reintegrate", the changes made on the branch are collected and effectively
"replayed" on the trunk, which will have the desired result regardless of
whether or not additional changes to trunk have already been made.
So, a specific decision must be made as to whether or not "reintegrate" should
be used, and the correct answer depends on whether or not the branch receives
updates from trunk during its life.
As long as the correct choice is made each time a branch is merged, then no
changes will be undone or "overridden".
(It would be really nice if Subversion could detect that a branch has received
updates from the origin and follow the best practice of "do the right thing by
default", but...it is what it is!)
-Message Disclaimer-
This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to conn...@principal.com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.
Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.
While this communication may be used to promote or market a transaction
or an idea that is discussed in the publication, it is intended to provide
general information about the subject matter covered and is provided with
the understanding that The Principal is not rendering legal, accounting,
or tax advice. It is not a marketed opinion and may not be used to avoid
penalties under the Internal Revenue Code. You should consult with
appropriate counsel or other advisors on all matters pertaining to legal,
tax, or accounting obligations and requirements.
Re: Upgrading from 1.6.5 (Fedora) to 1.6.16 (built from source)
On 07/03/2011 22:11 Jim Garrison ha scritto: > The last version available on the Fedora update site > for my system (Fedora 10) is 1.6.5, and I need the fixes > for Tree Conflict resolution that shipped in 1.6.6 and > later versions. > > Is there anything special to upgrading other than building > 1.6.16 from source, uninstalling the Fedora svn RPM and > hooking up Apache and the repository to the new version? Just install the Fedora 10 source RPM and replace the source package with the one downloaded from the subversion site (and change the version numbers in the specs file accordingly), rebuild all and you'll have a complete set of RPMs ready to update with yum localupdate.
svn:externals handling with svn merge --reintegrate
Having an issue where I have a checkout of trunk and I do a svn merge --reintegrate of a branch. That branch has added a directory and within that directory it has added a svn:external and when I do an svn up at the top level of trunk, it never downloads the external until I commit the reintegrated merge. I want to however test the reintegrated code before I commit. When I svn up, it doesn't see the external and goes on about its day. If I go to the directory where the external was added, then it hangs the SVN client, if I go one directory down, it doesn't see the external. I tried SVN 1.6.12 client and server. Then I upgraded both to SVN 1.6.16 and that didn't work either. -- Doug Goldstein
ra_replay, mergeinfo and externals
Hello, When replaying a revision merging an svn:externals property from a branch B to another A, using the svn python binding for svn_ra_replay, I get a property change event for svn:mergeinfo, but no event for the svn:externals property being merged into A. Is it expected? I hoped the replay API would generate all the events necessary to recreate the repository being replayed without additional calls. Do I need to retrieve the merged properties manually? This is with macports "svn, version 1.6.13 (r1002816)". A script to reproduce the input repository is attached. -- Patrick Mézard mergeexternals.sh Description: application/shellscript
Re: pre-lock.bat Failed in Repo browser
Michael Diers wrote on Tue, Mar 08, 2011 at 09:39:11 +: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2011-03-08 06:51, Waseem Bokhari wrote: > > Hi Experts! > >Below is the "pre-lock.bat " Script > > > > Only User who lock the file can unlock the file. Other users are > > forbidden to Unlock file. > [...] > > *Issue/Problem!!* > > > > This scenario failed in Repo Browser. Any one can Unlock File/Folder > > through Repo Browser. > > > > Please advice me accordingly. > > Waseem, > > that's too little information to give advice. Tell us about your > repository and client setup. > > Wild guess: are you perhaps using the file:// access method when > browsing the repository? Hook scripts are run by the Subversion server > process. Using the file:// access method effectively disables them. > Are you sure? Last I checked, normal clients didn't do authn/authz over file://, but did run hooks normally. > http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-repository.html#tsvn-repository-create > > http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-repository-hooks.html > > - -- > Michael Diers, elego Software Solutions GmbH, http://www.elego.de > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (Cygwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk11+T8ACgkQcEKlWnqVgz3cWgCgrGAuUSuFjKjf0U/+fM2/kZoR > gucAnRgp1IFwcqHsvgtkyCH+789pG18z > =GSif > -END PGP SIGNATURE-
Re: ra_replay, mergeinfo and externals
Does svnsync manage to replicate that svn:externals property? If yes, then the replay API does provide it to you. Patrick Mézard wrote on Tue, Mar 08, 2011 at 22:23:04 +0100: > Hello, > > When replaying a revision merging an svn:externals property from a branch B > to another A, using the svn python binding for svn_ra_replay, I get a > property change event for svn:mergeinfo, but no event for the svn:externals > property being merged into A. Is it expected? > > I hoped the replay API would generate all the events necessary to recreate > the repository being replayed without additional calls. Do I need to retrieve > the merged properties manually? > > This is with macports "svn, version 1.6.13 (r1002816)". A script to reproduce > the input repository is attached. > -- > Patrick Mézard
Re: Upgrading from 1.6.5 (Fedora) to 1.6.16 (built from source)
On Tue, Mar 8, 2011 at 6:12 PM, Marco Maccaferri wrote: > On 07/03/2011 22:11 Jim Garrison ha scritto: > >> The last version available on the Fedora update site >> for my system (Fedora 10) is 1.6.5, and I need the fixes >> for Tree Conflict resolution that shipped in 1.6.6 and >> later versions. >> >> Is there anything special to upgrading other than building >> 1.6.16 from source, uninstalling the Fedora svn RPM and >> hooking up Apache and the repository to the new version? > > Just install the Fedora 10 source RPM and replace the source package with > the one downloaded from the subversion site (and change the version numbers > in the specs file accordingly), rebuild all and you'll have a complete set > of RPMs ready to update with yum localupdate. You *wish*. Unless you've tested it, there may have been slight but significant build structure changes. This is precisely what I've encountered in the 1.6.15 to 1.6.16 upgrades for RPMforge building, and it's quite frustrating. The "rpath" patch, for example, is now rejected. Please don't tell unsuspecting developers that such a complex project is "plug and play" compatible. While it's often true, Subversion is one of the projects where it is most likely not to be true due to its extensive integration of separate components such as swig, neon, SSL, WebDAV, Apache, Python, and SSH. Don't *start* me on the Python dependencies.
