Advice on handing common code
All, I am setting up a new repository and have a question on how to handle “common” code. Common refers to code which is shared across the multiple systems that we deploy. In addition to the common code, we also have system-specfic software (custom code). Given the typical SVN layout, what’s a recommended way to manage this, especially when creating release tags? In this model, we include the /trunk/common_version1/application_1 ../../application_2 ./../application_3 /trunk/system1/application_1 ../../application_2 ../../application_3 /tags/system1/Rel_1 [where this may include the system1 apps plus common_version1/application_1 and application 3] ../system2/application_1 ../system2/application_2 ../system2/application_3 /tags/system2/Rel_1 [where this may include system2 apps plus common_version1/application_1, application_2 and application3]
svn:externals - svn: E200009: Targets must be working copy paths
Hello, I am attempting to set the svn:externals property via the command line, in hopes of ultimately creating a batch file/script as we have a huge number of externals to set. That dilemma aside, when I run the command, I get the message show below. My expectation is that this will set the prop value on "system_802" where it will pull in the code from "system_800". I am running the command in a directory where I have the "system_800" code checked out (ie my working copy path), so I don't know why I am getting the "Targets must be working copy paths" message. C:\Temp\800>svn propset svn:externals svn://3.X.X.X//trunk/Customer1/system_800/ver_1.0 svn://3.X.X/Customer1/system_802/ver_1.0 svn: E29: Targets must be working copy paths c:\Temp\8500>svn propset -r149 svn:externals svn://3.X.X.X/trunk/Customer1/system_800/ver_1.0 svn://3.X.X.X/trunk/Customer1/system_802/ver_1.0 svn: E205000: Try 'svn help' for more info svn: E205000: Cannot specify revision for setting versioned property 'svn:externals' Your guidance is much needed and appreciated. Amad
RE: svn:externals - svn: E200009: Targets must be working copy paths
Ryan, Thank you for the "teach a man to fish" approach. Though I didn't find the documentation to be very clear, I was able to set the property using the syntax below. c:\Temp\800>svn propset svn:externals "ver_1.0 svn://3.x.x.x/trunk/Customer1/system_800/ver_1.0" . property 'svn:externals' set on '.' This worked for the directory listed above. I then added several external definitions, but when I finally committed and checked out, it seems that only the last definition was applied. Evidently I overwrote the previous definitions. Can I add multiple external definitions? If it's in the "svn help propset", I am not seeing it. Amad
svn:externals - process question
Hello, My question is more process related with using svn:externals. In my testing, it seems that the svn:externals links are bi-directional. Changes are instantly propagated via the magic of svn:externals. 1. How do users preserve the integrity of a tag (which was created off a branch which had svn:externals)? Does one simply delete the svn:externals link once the tag is created? 2. In the case of common code shared between different projects (link from one to many), how are changes to the projects tracked? Say, projects 1, 2 and 3 all use common code. If project 1 makes changes to common (in addition to other changes) and is slated for a release, what now about projects 2 and 3? They too must be tagged to reflect the changes? Is the the "normal" practice? It seems like overhead to have to track and tag all projects affected by common. What are other ways of handling this in SVN? Amad Sorry for the double posts. Not sure what the protocol is on posting to different lists.
Re: svn:externals - svn: E200009: Targets must be working copy paths
Ryan: I was able to set multiple external definitions using the --file option. Worked pretty well, actually considering how challenging everything else has been so far! One last question on this topic. I want to pin the external definition to a known revision using something this shortened command, but it's not working. The "-r 109" being the revision I want to pin to. c:\Temp\800>svn propset svn:externals -r 109 . svn: E205000: Cannot specify revision for setting versioned property 'svn:externals' Andreas: I will provide feedback on the documentation shortly. On Wed, Jan 30, 2013 at 4:38 PM, Ryan Schmidt < subversion-20...@ryandesign.com> wrote: > > On Jan 30, 2013, at 14:14, C M wrote: > > > Thank you for the "teach a man to fish" approach. Though I didn't find > the documentation to be very clear, I was able to set the property using > the syntax below. > > > > > > c:\Temp\800>svn propset svn:externals "ver_1.0 > svn://3.x.x.x/trunk/Customer1/system_800/ver_1.0" . > > property 'svn:externals' set on '.' > > > > This worked for the directory listed above. I then added several > external definitions, but when I finally committed and checked out, it > seems that only the last definition was applied. Evidently I overwrote the > previous definitions. > > > > Can I add multiple external definitions? If it's in the "svn help > propset", I am not seeing it. > > Yes you can have multiple externals definitions, one on each line of the > svn:externals property. Setting a multiline property on the command line > via "svn propset" is difficult, so instead try "svn propedit svn:externals > ." (and type the multiline externals into the interactive editor) or "svn > propset svn:externals --file X ." (and provide a file X containing the > multiline externals). > > >
Resolved: svn:externals - svn: E200009: Targets must be working copy paths
Everything is working now as desired..I can set multiple externals with specific rev numbers attached. Thank you all for your help! Regards. Amad On Fri, Feb 1, 2013 at 12:32 PM, Daniel Shahaf wrote: > Ryan Schmidt wrote on Fri, Feb 01, 2013 at 12:29:32 -0600: > > > > On Feb 1, 2013, at 12:24, Ryan Schmidt wrote: > > > > > On Feb 1, 2013, at 11:00, C M wrote: > > > > > >> I was able to set multiple external definitions using the --file > option. Worked pretty well, actually considering how challenging everything > else has been so far! > > >> > > >> One last question on this topic. I want to pin the external > definition to a known revision using something this shortened command, but > it's not working. The "-r 109" being the revision I want to pin to. > > >> > > >> c:\Temp\800>svn propset svn:externals -r 109 . > > >> > > >> svn: E205000: Cannot specify revision for setting versioned property > 'svn:externals' > > > > > > The revision number to which you want to pin each external needs to be > listed on the corresponding line of the svn:externals property. Read the > documentation again; I recommend following the example after the paragraph > which starts "Or, making use of the peg revision syntax". > > > > > > http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html > > > > Or, in the example you gave above of wanting to pull a specific revision > of just a single external, you just need quotes: > > > > svn propset svn:externals "-r 109 " . > > > > You need a '--' argument here to prevent an argument parsing error. > > svn propset -- svn:externals "-r 109 " ./ > > > Or better yet, using peg revision syntax: > > > > svn propset svn:externals "@109" . > > > > >
Re: svn copy and history - quick question
As a SVN newbie myself, I suggest you set up a SVN sandbox and try out the basic functionality within it. You will get a better understanding of how SVN works by trying out various commands. Regards. Amad On Thu, Feb 14, 2013 at 1:58 PM, Z W wrote: > Hi All > > We are SVN newbies here. > We plan to do an svn copy (of a branch to another trunk). > Does "svn copy" command copies all the history of the file and folder > revisoins too ? > > Thanks >
Add new files
Dear All, I need to add new files to my project. Is there a way to create an empty working copy where I just copy the new files into it and then commit them? It seems unnecessary to have to checkout the whole project (or parts of it) to the working copy when I don't need to update anything existing. Am I missing something here? Amad
Question: svn list command
The "svn list" command does not list directory entries if they are svn:externals. Assuming this is by design, is there a way for it list externals also?
Re: Question: svn list command
But that means I have to create a working copy. I don't necessarily want to do that if all I am looking for is a directory listing. On Wed, Feb 20, 2013 at 11:06 AM, Geoff Hoffman wrote: > > > On Wed, Feb 20, 2013 at 10:02 AM, C M wrote: > >> The "svn list" command does not list directory entries if they are >> svn:externals. >> >> Assuming this is by design, is there a way for it list externals also? >> > > > cd into the local directory defined by your external, then svn list there. > > > Connect with us on twitter <http://twitter.com/cardinalpath>, > google+<https://plus.google.com/108076800625872227241/posts> > , facebook <http://www.facebook.com/CardinalPath>,** or > linkedin<http://www.linkedin.com/company/cardinal-path> > . > > Catch our next training in St Louis Feb 25 - Mar > 1<http://training.cardinalpath.com/google-adwords-analytics/saint-louis/?utm_campaign=cp-cpt&utm_source=sig-referral&utm_medium=email&utm_content=stlouis-2013-02-25> > , Vancouver Mar 4 - > 8<http://training.cardinalpath.com/google-adwords-analytics/vancouver/?utm_campaign=cp-cpt&utm_source=sig-referral&utm_medium=email&utm_content=vancouver-2013-03-04> > , New York City Mar 11 - 15 <http://goo.gl/y4Ojj>, Atlanta Apr 10 - > 12<http://goo.gl/oJGyd> > or See All <http://cpath.it/Jkrs3s>. > > This email, including any attachments, is for the sole use of the intended > recipient and may contain confidential information. If you are not the > intended recipient, please immediately notify us by reply email or by > telephone, delete this email and destroy any copies. Thank you. > >
Tagging svn:externals
It seems that SVN does not tag svn:externals. We have defined a structure such that child projects have link from a parent project. Parent project -> child project_1 -> child project_2 -> child project_3 However, when you go to tag a release for a child, there's nothing in the /tags/Rel_X as I would normally expect. What's going on here? Amad
Re: Tagging svn:externals
The external definitions do specify a revision. That part is working fine. I am just not clear on why a simple copy (tag) doesn't work against externals. On Wed, Feb 20, 2013 at 11:42 AM, Geoff Hoffman wrote: > Externals are separate repositories by design. You should reference > externals to a specific revision, or tag the externals first and rewrite > your externals to point to the tagged externals. > > > > > On Wed, Feb 20, 2013 at 10:28 AM, C M wrote: > >> It seems that SVN does not tag svn:externals. >> >> We have defined a structure such that child projects have link from a >> parent project. >> >> Parent project -> child project_1 >> -> child project_2 >> -> child project_3 >> >> However, when you go to tag a release for a child, there's nothing in the >> /tags/Rel_X as I would normally expect. >> >> What's going on here? >> Amad >> > > > Connect with us on twitter <http://twitter.com/cardinalpath>, > google+<https://plus.google.com/108076800625872227241/posts> > , facebook <http://www.facebook.com/CardinalPath>,** or > linkedin<http://www.linkedin.com/company/cardinal-path> > . > > Catch our next training in St Louis Feb 25 - Mar > 1<http://training.cardinalpath.com/google-adwords-analytics/saint-louis/?utm_campaign=cp-cpt&utm_source=sig-referral&utm_medium=email&utm_content=stlouis-2013-02-25> > , Vancouver Mar 4 - > 8<http://training.cardinalpath.com/google-adwords-analytics/vancouver/?utm_campaign=cp-cpt&utm_source=sig-referral&utm_medium=email&utm_content=vancouver-2013-03-04> > , New York City Mar 11 - 15 <http://goo.gl/y4Ojj>, Atlanta Apr 10 - > 12<http://goo.gl/oJGyd> > or See All <http://cpath.it/Jkrs3s>. > > This email, including any attachments, is for the sole use of the intended > recipient and may contain confidential information. If you are not the > intended recipient, please immediately notify us by reply email or by > telephone, delete this email and destroy any copies. Thank you. > >
Re: Tagging svn:externals
I am not seeing anything in: /tags/Rel_1.0. Mind you I am using the Tortoise SVN 1.7 client to do the copy. On Wed, Feb 20, 2013 at 12:05 PM, Les Mikesell wrote: > On Wed, Feb 20, 2013 at 11:58 AM, C M wrote: > > The external definitions do specify a revision. That part is working > fine. > > > > I am just not clear on why a simple copy (tag) doesn't work against > > externals. > > What do you mean by 'doesn't work'? The copy should have the same > externals as the source. > > -- > Les Mikesell > lesmikes...@gmail.com >
Update externals - trunk -> branch
Hello, When svn: external properties are updated on trunk, how can those updates be propagated to developer branches that are coming off the trunk? Is there a svn command I can run to “push” those updates? I tried "svn update" but that didn't do the job. Please advise. Amad.
Re: Update externals - trunk -> branch
Hmm, I wouldn't have expect that a merge would be needed to update a property value. Is there another way this can be accomplished? Our team is new to SVN and feeling its way around the tool. On Tue, Mar 26, 2013 at 10:12 AM, Stefan Sperling wrote: > On Tue, Mar 26, 2013 at 10:05:10AM -0500, C M wrote: > > Hello, > > > > When svn: external properties are updated on trunk, how can those updates > > be propagated to developer branches that are coming off the trunk? > > By using the 'svn merge' command. > See http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html >
Question re: Removing Externals
We've had mixed results using svn externals and have decided to remove them altogether. Mostly, bi-directional changes we weren't expecting. This was also because of our inexperience with SVN and using externals. In any event, my questions are: 1. If I delete the externals from /trunk, what will happen to the tags that contained the external references? Will they become useable? I am not sure what to expect. 2. Do I need to delete them from /trunk and /tags/Rel_X (ie each rel tag which had the externals).? 3. If I delete externals from /trunk, what will happen to any development branches that were based off trunk and contained externals references? I am afraid of creating a bigger mess than we are in at the moment. Any advice/gotchas are most appreciated. Amad.
Files on trunk overwritten...
I am certain there is simple way out of this situation. Some files were committed to trunk which have incorrect updates. What's the easiest way to roll back to the previous versions (before the erroneous changes were committed)? Should I checkout the previous revision and commit them over the erroneous changes? Or is there some way to handle this? TIA, Amad
Re: Files on trunk overwritten...
Deleting the trunk is not an option. To do the reverse merge, I created a working copy (which includes the files which are incorrect and I want to revert via the merge). Within my working copy, I typed: svn merge -c -177 https://trunk/path_to_directory 177 being the revision I want to roll back to but nothing happens. svn status shows nothing. What am I missing? On Fri, Apr 26, 2013 at 12:33 AM, Lorenz wrote: > C M wrote: > >Some files were committed to trunk which have incorrect updates. > > > >What's the easiest way to roll back to the previous versions (before the > >erroneous changes were committed)? > > another way is to delete the trunk and reestablish it by copying the > last correct trunk revision. > > This way a log of trunk head won't show the intermediate (between the > revision of the copy source ad the copy itself) commits to trunk. > Only the copy of the earlier revision will show up. > > ---x--- ---y z--- ... > \ / > - > > If there was only one objectionable commit I would go with the reverse > merge though. > -- > > Lorenz > >
Re: Files on trunk overwritten...
The working copy (head revision) is at 661. 177 is what I want to go back to. Is this the syntax to use (from within the working copy: svn merge -r661:177? On Fri, Apr 26, 2013 at 8:53 PM, Les Mikesell wrote: > On Fri, Apr 26, 2013 at 6:18 PM, C M wrote: > > Deleting the trunk is not an option. > > > > To do the reverse merge, I created a working copy (which includes the > files > > which are incorrect and I want to revert via the merge). > > Within my working copy, I typed: > > > > svn merge -c -177 https://trunk/path_to_directory > > > > 177 being the revision I want to roll back to but nothing happens. > > > > svn status shows nothing. What am I missing? > > That's not saying you want to roll back from current to r177, it says > undo the change in the rev 177 commit. That is, -r177:176. Is that > exactly when the change you want to remove happened? > > -- >Les Mikesell > lesmikes...@gmail.com >
Re: Files on trunk overwritten...
This syntax did the trick: svn merge -r661:177 --dry-run https://XXX/trunk/directory_path In preview mode, SVN showed me the files it was going to update. That list matched the files we knew had been modified erroneously. There weren't any changes to that particular directory contents since r177. I re-ran it without the dry run, then ran diff after the update. We are set. Thank you. Amad On Mon, Apr 29, 2013 at 1:41 PM, Les Mikesell wrote: > On Mon, Apr 29, 2013 at 1:23 PM, C M wrote: > > The working copy (head revision) is at 661. 177 is what I want to go back > > to. > > > > Is this the syntax to use (from within the working copy: > > > > svn merge -r661:177? > > Yes but that should undo all changes after 177 and you might only want > the next commit or so if more changes were added later. In any case > it is fairly easy and safe to experiment - just use a working copy > with no other changes and don't commit until you get what you want > (and you can tell by diffing against the version where things were > correct). If you don't like the merge results, just revert to the > unmodified checkout and try again. > > -- >Les Mikesell > lesmikes...@gmail.com >
SVN Import command
Hello, We plan to use a SVN repository as a deployment mechanism so technicians can download and install the application binaries for a customer system. The directory where we want them to download from will always have the "current" binaries. The issue I am facing is how to replace (overwrite) the application binary in the directory when there's a new version of it. I tried to use the "svn import" to overwrite but it doesn't seem to like that. I also tried it with the "svn import --force" svn: E150002: Path 'svn://X.XX.XXX.XX/' already exists Is there another way to accomplish this? Amad
Re: SVN Import command
I don't understand why I can't simply over-write the existing file in the directory? On many occasions, a build may only result in one new executable. To have to delete/rename the entire directory seems like overkill. And for the most part, we only have one top level directory below which all the executables are stored. On Fri, May 3, 2013 at 11:44 AM, Les Mikesell wrote: > On Fri, May 3, 2013 at 11:23 AM, C M wrote: > > We plan to use a SVN repository as a deployment mechanism so technicians > can > > download and install the application binaries for a customer system. > > > > The directory where we want them to download from will always have the > > "current" binaries. > > > > The issue I am facing is how to replace (overwrite) the application > binary > > in the directory when there's a new version of it. > > > > I tried to use the "svn import" to overwrite but it doesn't seem to like > > that. I also tried it with the "svn import --force" > > > > > > svn: E150002: Path 'svn://X.XX.XXX.XX/' already exists > > > > Is there another way to accomplish this? > > Basically, after your initial import you want to delete or rename the > directory you imported and check it back out as a working copy. Then > to make changes you will overwrite the files in the working copy with > the new versions and 'svn commit' to update the repository. If you > add new files you must 'svn add' them before the commit (if it is > automated, you might 'svn add *' and ignore the error messages about > existing items). Depending on how 'visible' you want to make the > versioning, you might (or might not...) want to arrange the usual > /trunk, /branches, /tags layout for your files, always updating the > trunk copy and after each commit, copy it to a tag with your own > revision numbering scheme. Also, you might use something like viewvc > for web browser downloads and the ability to pick back-rev versions if > needed. Even without tagging, this will give you access to any > version you have committed. > > -- >Les Mikesell > lesmikes...@gmail.com >
Re: SVN Import command
This is precisely what we are looking for. For the most part, we distribute a new executable for each update, so an overwrite is all we care about. The main reason we are moving to SVN is because the current deployment process uses a fileshare where updates are pushed out to. At least with SVN, we'll have some traceability. Thank you to everyone for your input. Amad. On Fri, May 3, 2013 at 12:43 PM, wrote: > > I don't understand why I can't simply over-write the existing file in the > > directory? On many occasions, a build may only result in one new > executable. > > To have to delete/rename the entire directory seems like overkill. > > While it kinda defeats the purpose of Subversion, you can use the svnmucc > utility to "overwrite" an existing file, even with the same contents: > > svnmucc put test.txt http://server/kmr_test/trunk/foo/test.txt -m"Add > file" > r479 committed by kmradke at 2013-05-03T17:36:00.823078Z > > svnmucc put test.txt http://server/kmr_test/trunk/foo/test.txt-m"Overwrite > file" > > svn log http://server/kmr_test/trunk/foo/test.txt > > r480 | kmradke | 2013-05-03 12:36:12 -0500 (Fri, 03 May 2013) | 1 line > > Overwrite file > > r479 | kmradke | 2013-05-03 12:36:00 -0500 (Fri, 03 May 2013) | 1 line > > Add file > > > svn diff -r479:480 http://server/kmr_test/trunk/foo/test.txt > > > In this case no local working copy is needed, but it will happily > let you overwrite the file with the same contents and create create > a new subversion revision. Note that the complete file contents > will be sent to the server each time. > > If you are on Windows I'm not sure what distributions include svnmucc. > (TortoiseSVN does not) > > Kevin R. > >
Ancestrally Related Error Message
Hello, Code for a new development effort was imported into a developer’s branch. Now we want merge his changes to trunk (which is currently empty). I tried the merge from both the command line and the Tortoise GUI and keep running into the “…must be ancestrally related…” message.I also tried the "ignore ancestry" option via the GUI. One, I don't understand why SVN thinks there is even an ancestral relationship betweeen the two locations? Two, how can I do to get around this error message? Amad
Re: Ancestrally Related Error Message
I think my earlier mistake might have been that I was using the --reintegrate option. Without it, I make some progress, but still not quite what I am expecting. Again, given that trunk is empty, why the "C" (tree conflicts)? I would expect all of then to be "A" (additions), no? The DEV_WC currently only shows the two dirs which SVN correctly recognized as additions. c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry https://path_to_branch/SCR_BR/ --- Merging r1191 through r1245 into '.': C ini C txt C graphics C MMI C backups C sysctrl Asysconfig Asysconfig\src Asysconfig\src\sysconfig Asysconfig\src\sysconfig.c Asysconfig\src\sysconfig_init.c Asysconfig\src\log Asysconfig\src\makefile Asysconfig\inc C cpu Amtl Amtl\lib Amtl\lib\mtl.lib Amtl\src Amtl\src\mtl_meter.c Amtl\src\mtl Amtl\src\makefile Amtl\src\mtl.c Amtl\inc Amtl\inc\mtl_meter.h C util_panel U . Summary of conflicts: Tree conflicts: 8 On Mon, Jun 17, 2013 at 10:38 AM, C. Michael Pilato wrote: > On 06/17/2013 11:19 AM, C M wrote: > > Hello, > > > > Code for a new development effort was imported into a developer’s branch. > > > > Now we want merge his changes to trunk (which is currently empty). > > > > I tried the merge from both the command line and the Tortoise GUI and > keep > > running into the “…must be ancestrally related…” message.I also tried the > > "ignore ancestry" option via the GUI. > > > > One, I don't understand why SVN thinks there is even an ancestral > > relationship betweeen the two locations? > > Subversion doesn't think there is. Rather, it knows there isn't. Hence > the > message. The error was introduced to prevent a common mistake folks make > when they misalign their merge sources and targets: > >$ svn merge ^/trunk branches >^C^C^Cdangit i meant to type "branches/my-branch"^C^Cagh! > > > Two, how can I do to get around this error message? > > Well... the --ignore-ancestry option was *supposed* to make that happen for > you. Perhaps there's a bug? > > You may need to give a more complete transcript of what you're trying, > including command-line examples and such. > > -- > C. Michael Pilato > CollabNet <> www.collab.net <> Enterprise Cloud Development > >
Re: Ancestrally Related Error Message
Running without the dry-run option doesn't do anything different (it still reports the conflicts). Yes, the diff shows the content I am expecting (at least for the text files). I ran "svn diff -r1190:1245 --summarize https://path_to_branch/SCR_BR/"; and see output like: M path_to_file M path_to_file M path_to_file Without the "--summarize" option, I see the file content which matches what we are expecting. This is for the text files which SVN identified as being conflicted. I have several developer branches to merge to trunk. If I can't get the merge to work, is doing a copy from the branch to trunk an option? Will that create further issues downstream? I know no one has a crystal ball, but I have limited experience with SVN and dont know what to expect. See example below = --- txt/pod_block.txt (revision 1190) +++ txt/pod_block.txt (revision 1245) @@ -1,7 +1,7 @@ On Mon, Jun 17, 2013 at 11:56 AM, C. Michael Pilato wrote: > On 06/17/2013 12:39 PM, C M wrote: > > I think my earlier mistake might have been that I was using the > > --reintegrate option. > > Without it, I make some progress, but still not quite what I am > expecting. > > > > Again, given that trunk is empty, why the "C" (tree conflicts)? I would > > expect all of then to be "A" (additions), no? > > > > The DEV_WC currently only shows the two dirs which SVN correctly > recognized > > as additions. > > > > c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry > > https://path_to_branch/SCR_BR/ > > > > --- Merging r1191 through r1245 into '.': > > Do these revision numbers (r1191 and r1245) match what you'd expect? What > happens if you do this: > >svn diff -r1190:1245 https://path_to_branch/SCR_BR/ > > Do you see exactly the additions that you would expect to see? > > -- > C. Michael Pilato > CollabNet <> www.collab.net <> Enterprise Cloud Development > >
Re: Ancestrally Related Error Message
We are on SVN 1.7.6. Trunk is empty because this is/was a new development effort. The code was directly imported into the developer's branch. I ran these two commans in the working copy and get the messages you mentioned. What does that mean? c:\Temp\DEV_WC>svn merge --dry-run --revision 1190:1233 c:\Temp\DEV_WC>svn status M . ! C MMI > local delete, incoming edit upon merge ! C graphics > local delete, incoming edit upon merge ! C hpu > local delete, incoming edit upon merge ! C ini > local delete, incoming edit upon merge ! C misc.backups > local delete, incoming edit upon merge A +mtl A +sysconfig ! C sysctrl > local delete, incoming edit upon merge ! C txt > local delete, incoming edit upon merge ! C util_panel > local delete, incoming edit upon merge Summary of conflicts: Tree conflicts: 8 On Mon, Jun 17, 2013 at 12:40 PM, Andrew Reedick wrote: > > > > From: C M [mailto:cmanalys...@gmail.com] > > Sent: Monday, June 17, 2013 12:39 PM > > To: C. Michael Pilato > > Cc: Subversion > > Subject: Re: Ancestrally Related Error Message > > > > I think my earlier mistake might have been that I was using the > --reintegrate option. > > Without it, I make some progress, but still not quite what I am > expecting. > > Again, given that trunk is empty, why the "C" (tree conflicts)? I would > expect all of then to be "A" (additions), no? > > The DEV_WC currently only shows the two dirs which SVN correctly > recognized as additions. > > > > c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry > https://path_to_branch/SCR_BR/ > > > > --- Merging r1191 through r1245 into '.': > > C ini > > C txt > > C graphics > > C MMI > > C backups > > C sysctrl > > > C cpu > > Amtl > > Summary of conflicts: > > Tree conflicts: 8 > > What kind of tree conflicts are they? 'svn status' should provide more > detail. Also, what version of svn are you using? 1.6? 1.7? > > Why is trunk empty? Because you deleted trunk after the branch was > created? (i.e. create branch, delete trunk/*, merge from branch.) > > I get the vague feeling that you have 'incoming add after delete'(?) type > messages on the directory conflicts. > > > >
Re: Ancestrally Related Error Message
Well, for what its worth, I was able to complete the "merge" following steps 3 -6 in this article. http://kirenpillay.blogspot.com/2012/07/svn-merge-tree-conflict-resolution.html I don't understand why SVN behaved the way it did and prevented the branch to trunk merge as expected.. On Mon, Jun 17, 2013 at 1:47 PM, Les Mikesell wrote: > On Mon, Jun 17, 2013 at 12:59 PM, C M wrote: > > We are on SVN 1.7.6. > > > > Trunk is empty because this is/was a new development effort. The code was > > directly imported into the developer's branch. > > > > I ran these two commans in the working copy and get the messages you > > mentioned. What does that mean? > > > > c:\Temp\DEV_WC>svn merge --dry-run --revision 1190:1233 > > c:\Temp\DEV_WC>svn status > > M . > > ! C MMI > > > local delete, incoming edit upon merge > [...] > > And you are merging into a working copy that is a checkout of the > empty trunk? Anyway if the trunk is empty you should get the same > result if you just copy the branch to it. > > -- >Les Mikesell > lesmikes...@gmail.com >
Shared branch vs single branch
What are some of the pros/cons of using a single/shared branch versus the private developer branch? We are having an internal debate within the team where the idea of a single/shared branch was proposed in reaction to two specific issues: 1. In the merge to trunk from individual developer branches, some code was lost. It remains unclear whether it was user error on part of the person doing the merge or the tool which caused the problem. In at least one case, a file was partially merged. 2. The combined functionality (features assigned to two different developers) was not included in the final application build and delivery. In this case, the assignments were made months apart and one feature was delivered without the other. The expectation is that a shared/single branch will correct these issues. I am curious to know what advice others can offer and what (if any) potential issues we may experience with the new paradigm. Thanks. Amad.
Re: Shared branch vs single branch
Unfortunately, we are lacking on processes and there's a definite lack of product management. But coming back to my original question: Are there any potential gotchas with using a single/shared branch? For now, that's the only change the team (and leadership) is looking to as the "solution". Our developers code on a Unix like platform and have little SVN experience to boot. The idea of turning over merging to them seems to be a recipe for disaster. I would prefer to let the CM team handle the merges and figure out what I did incorrectly to mess up the previous merges. On Mon, Sep 23, 2013 at 2:42 PM, Les Mikesell wrote: > On Mon, Sep 23, 2013 at 2:35 PM, Bob Archer wrote: > >> On Mon, Sep 23, 2013 at 1:50 PM, Bob Archer > wrote: > >> >> It really depends. I think all work for a specific release should be > done in a > >> single branch/folder. Many people follow the stable trunk model. In > this model > >> you generally do all work on trunk and then branch for a release. This > is the > >> same model svn itself is developed under. In this model you would also > use > >> what are called "feature" branches. This is generally for a feature/use > case that > >> will take more than a day to complete or will be worked on by more than > one > >> developer. > >> > > >> > Once again, it's up to the people not the tool to ensure your release > >> management is done properly. > >> > >> Well, sort-of. It is always a good idea to (a) include tests for new > >> code and (b) have a workflow that ensures that the tests are run and > >> that someone checks the results. Expecting one person to never make > >> a mistake just doesn't always work out. > > > > Isn't is up to the people to put those processes in place? To create the > correct workflow? To write the automation? > > > > I don't think I ever said it should be ONE person's responsibility to > manually do this work. Where did I say that? > > You didn't explicitly say it was one person's fault, but what you said > could easily be interpreted that way by anyone who had to ask the > question in the first placeYes, people have to set things up, > but there are tools that can help. > > -- >Les Mikesell > lesmikes...@gmail.com >
svn merge output: "R"
Hello. I ran "svn merge --reintegrate --dry-run" against branch. As part of the dry-run preview, several files are marked with: Rpath-to-file\src\Update.c What does the "R" mean? I haven't encountered it before. Can someone please explain? Thank you.
Re: svn merge output: "R"
Ben, I should have checked "svn help" before posting...thank you for the response. On Thu, Dec 5, 2013 at 11:32 AM, Ben Reser wrote: > On 12/5/13 9:29 AM, C M wrote: > > Hello. > > > > I ran "svn merge --reintegrate --dry-run" against branch. As part of the > > dry-run preview, several files are marked with: > > > > Rpath-to-file\src\Update.c > > > > What does the "R" mean? I haven't encountered it before. Can someone > please > > explain? > > Thank you. > > From `svn help merge`: > [[[ > For each merged item a line will be printed with characters reporting the > action taken. These characters have the following meaning: > > A Added > D Deleted > U Updated > C Conflict > G Merged > E Existed > R Replaced > ]]] > > File we deleted and then added or copied in again. >
Unable to browse repo
Does anyone know what this error means and how I can correct it? svn: E22: /.subversion/config:93: Option expected I am getting this message while trying to browse the SVN repos from a build server. This was working fine a few days ago (when I last accessed the repo from this server). My SVN credentials are valid since I can browse the repos from other servers. Thanks Amad
Re: Unable to browse repo
For what it's worth, line 93 refers in the config file is listed below. As far as I know, this file hasn't been modfied recently by anyone. At least that's what my team members tell me. 92 ### put last-committed timestamps on every file touched. 93 use-commit-times = yes 94 ### Set no-unlock to prevent 'svn commit' from automatically On Wed, Feb 12, 2014 at 11:10 AM, C M wrote: > Does anyone know what this error means and how I can correct it? > > svn: E22: /.subversion/config:93: Option expected > > I am getting this message while trying to browse the SVN repos from a > build server. This was working fine a few days ago (when I last accessed > the repo from this server). > > My SVN credentials are valid since I can browse the repos from other > servers. > > Thanks > Amad >
Re: Unable to browse repo
Dave, Thank you for the tip...that fixed the issue. Best regards, Amad On Wed, Feb 12, 2014 at 11:50 AM, Dave Huang wrote: > On 2014-02-12 11:46 AM, C M wrote: > >> For what it's worth, line 93 refers in the config file is listed below. >> As far as I know, this file hasn't been modfied recently by anyone. At >> least that's what my team members tell me. >> >> >> 92 ### put last-committed timestamps on every file touched. >> 93 use-commit-times = yes >> 94 ### Set no-unlock to prevent 'svn commit' from automatically >> > > It looks like there's a space at the beginning of line 93... try removing > it. > >
Bug report: Can't parse lock/entries hashfile. Serialized hash missing terminator
Dear Sir We got this error "Can't parse lock/entries hashfile /foldername/filename. Serialized hash missing terminator" in one of our repositories when trying to browse or update the repository.Running svnadmin lslock on the repository folder on the server also produced the same error message.To "fix" the problem, we had to delete the entire /repofolder/locks folder (couldn't run svnadmin rmlock because it also produced the same error). We are using subversion-1.8.1 on a Freebsd 9.1 server (32 bit).Is there a bug in Subversion? We are not aware of any ungraceful server shutdowns. Thank you CM Gui
