Re: Strange behavior
On 8/9/13 10:27 AM, John Maher wrote: > And svn status returns this: > C Build.bat > > local add, incoming add upon merge You svn add Build.bat in trunk. Later you svn add Build.bat in your branch. Subversion sees those as separate objects with individual history. If you had svn add Build.bat in the trunk, then merged to the branch (without svn add Build.bat in the branch), then you'd have the same object with history that has diverged. In this scenario you can make changes in the trunk and in the branch (history for the one object diverges) and later merge the changes between the branches (synchronize the diverging histories). So to recap, in your current scenario you have two objects each with one history. In the correct scenario you have one object with two related histories. The svn book details how to deal with a scenario like this. You have to svn delete Build.bat in the branch (but keep the changes somewhere), commit, then merge from trunk (might need to use the --force argument, I forget) putting Build.bat from trunk in your branch, then manually merge the changes from the old Build.bat and the new Build.bat. Once you fix this you should never need to perform this process again. The conflicts reporting "local delete, incoming delete upon merge" occur due to a similar reason. -- Edwin G. Castro
Re: Strange behavior
On 8/12/13 6:17 AM, John Maher wrote: > Are you sure this is the only way? It would seem odd that this toll does not > provide a way to import an enterprise level application without ignoring the > compiler generated files. In cases like this I perform a "clean" operation that removes compiler generated files. I would also remove any user specific files as by definition they should not be part of the repository. -- Edwin
Re: Strange behavior
On 8/12/13 10:57 AM, John Maher wrote: > But then again perhaps those are the people who use subversion for the > simplest of builds. At my previous employer I was partly responsible for a codebase in subversion whose trunk was 2+ GB large. The codebase included over 1400 C#, C++, SQL, and WiX projects. I think many of us have very complicated builds. We simply choose to use the correct tool for the job. Working on Windows I wrote many PowerShell scripts to help me manage bulk operations. I have no evidence but I suspect most of us have lots of experience working with very large codebases in subversion. Suggesting that we have the "simplest of builds" comes across as elitist which is odd coming from an obvious beginner. There is clear evidence that there's a cognitive mismatch between your current understanding and how subversion is intended to be used. We're here to help you but that help will come these discussions occur with respect. Sometimes it is better to present the experts with the problem you are trying to solve including how you've attempted to solve it, accepting the possibility that your current approach may not be the best approach. Seems like I keep hearing "you're doing it wrong" from the list and you keep responding with "I don't care, how do accomplish this anyway." I don't think that's a good attitude to take. -- Edwin
Re: Switching
On 8/22/13 7:59 AM, Les Mikesell wrote:
> On Thu, Aug 22, 2013 at 6:30 AM, John Maher wrote:
>> >
>> > @Andrew there is no need for a svn copy. I do not want to copy a feature
>> > in one branch to another; I wish to keep the code isolated.
>> >
>> > And yes I know subversion won't delete unversioned files, I appreciate the
>> > info on how subversion works. Some of it was helpful. I was hoping to
>> > hear how others may have solved the same problem.
> Your problem is not so much that svn doesn't deleted the unversioned
> files, but that it can't delete the directory containing them.
>
>> > But it seems the only answer is a tedious and manual process for the
>> > simplest of enhancements.
> Don't your build tools have commands to remove any spurious files
> they've created or some equivalent of 'make clean' that you can run to
> remove the clutter in a non-tedious way so that svn switch is free to
> work correctly with the versioned content?
>
I typically run into this problem when a "build output" directory exists
due to having built the project that doesn't exist in the other branch.
Something along these lines:
root/
+-- projectA/
| +-- bin/
| | +-- debug/
| | | +-- projectA.dll
| | +-- release/
| | +-- projectA.dll
| +-- src/
+-- projectB/
+-- bin/
| +-- debug/
| | +-- projectB.dll
| +-- release/
| +-- projectB.dll
+-- src/
Let's say in branch1 both projects exist but in branch2 only projectB
exists. The tree above would obviously imply I am currently on branch1.
I would have added the bin directory to svn:ignore on both the projectA
and projectB directories as I don't want to accidentally commit the
contents of the bin directory. The tree above is only an example. The
branches I'm used to dealing with contain hundreds of such projects and
building all of them can take up to 2 hours even on relatively fast
hardware.
If projectA has been built while I'm working on branch1 and I want to
svn switch to branch2, then svn will attempt to delete root/projectA/
but it can't because root/projectA/bin/ still exists. The switch leaves
behind root/projectA/ as unversioned (including the root/projectA/bin/
directory). Now that I'm done working with branch2 I try to svn switch
back to branch1 and svn fails to add root/projectA/ because it already
exists in the working copy unversioned.
We have a root build script that can run the clean target on all of our
projects. Alternatively, I could run clean on individual projects prior
to a switch but that requires that I know which projects do not exist on
the target branch. I could also use the --force argument to svn switch
but it carries it's own hazards. From svn help switch:
If --force is used, unversioned obstructing paths in the working
copy do not automatically cause a failure if the switch attempts to
add the same path. If the obstructing path is the same type (file
or directory) as the corresponding path in the repository it becomes
versioned but its contents are left 'as-is' in the working copy.
This means that an obstructing directory's unversioned children may
also obstruct and become versioned. For files, any content differences
between the obstruction and the repository are treated like a local
modification to the working copy. All properties from the repository
are applied to the obstructing path.
I'm particularly worried by "This means that an obstructing directory's
unversioned children may also obstruct and become versioned." You might
end up committing files you don't want to commit by using svn switch
--force so you'll want to be very careful. It would probably be a good
idea to follow up svn switch --force with svn status to see if anything
becomes versioned that shouldn't be.
Even though our builds can be quite long, I typically find it much safer
to simply clean all of the projects prior to performing svn switch. I
typically don't use our root build script to clean the projects because
it takes a long time loading up all of those different
projects/solutions to run the clean target. Since I'm on Windows I use
PowerShell to find all ignored and unversioned items and manually delete
them:
svn status --no-ignore --ignore-externals | Where-Object { $_ -match
'^[I?]' } | Remove-Item -Force -Recurse -Path { $_.Substring(8) } -Verbose
I've needed to update the substring index in the past because a new svn
release changed the svn status format on me.
Performing this kind of cleanup allowed svn switch to work correctly
every time. Then again, this does imply that every thing must be rebuilt
post switch which can be very painful when you have as many projects as
we do. If some of the ignored/unversioned files are user files that
should not be versioned, then cleaning like this creates additional
problems. We've worked around these problems by requiring that user
files are not used and adding a target to our root build script
Re: Switching
I agree with Les here on the point about making sure you can automate the process correctly only with versioned resources. In our CI builds we have the versioned resources configured so that all tests are executed every time. Developers execute subsets of tests through their tools and are expected to manage their tools on their own. Sounds like there might be a trade off between copying/reconfiguring if they choose one working copy per branch and reconfiguring if they clean/switch between branches. That might be best left as an individual developer decision. On 8/22/13 10:58 AM, John Maher wrote: > You are correct that there will be issues with a fresh checkout. But I can > live with that. The code will not be affected, just the way the code is > tested. Once the developer decides on how they wish to test I do not want to > A) lose those changes or B) step on the choices others have made by > versioning it. > > Think config or settings file. > > -Original Message- > From: Les Mikesell [mailto:lesmikes...@gmail.com] > Sent: Thursday, August 22, 2013 1:53 PM > To: John Maher > Cc: Edwin Castro; users@subversion.apache.org > Subject: Re: Switching > > On Thu, Aug 22, 2013 at 12:43 PM, John Maher wrote: >> The clean up script is a good idea but won't work here. We have mostly all >> class libraries. One executable. This means to test we need to specify an >> application in the project. Some developers use the exe while some use a >> tool made just for testing the classes. This information is in the *.sou >> files which are unversioned for this reason. So we don't want to delete >> them (as I incorrectly stated somewhere) but ignore them. > You are sort-of asking for trouble if you have any dependency on unversioned > files being in a workspace at all, much less for them to continue to exist > when switching among versions with/without the > containing directories. I'd advise stepping back from the immediate > problem and thinking of processes that will always work with a fresh checkout > so that in the future you can use build automation tools like jenkins, > relying only on the contents of the repository even when the build happens on > a new host. It will simply your life even for manual operations if you can > count on that. >
Re: Switching
On 8/22/13 10:54 AM, John Maher wrote: > This happens even if you do not do a build. There is a class library in one > branch but not the other mixed with unversioned files that I can do nothing > about. Statements like this make me believe that build system is broken. I would expect the svn switch like problems on nearly any SCM you use that has the ability to switch a single working copy (or workspace, client, what-have-you) between branches. My knee jerk reaction in situations like this is to fix the build system. Are you sure there is nothing you can do? Perhaps you can suggests a simple fix like moving the versioned class library to a location that is always versioned. For example, instead of referencing a class library that lives in a bin/ directory it is better to keep the class library in a lib/ directory instead. Build output goes in the unversioned bin/ directory and versioned resources go in the lib/ directory. -- Edwin G. Castro
Re: Switching
You said, and I quote, "There is a class library in one branch but not in the other mixed with unversioned files that I can do nothing about." I misread that statement to mean you had compiled output committed in one branch. You seem to be trying to point out that the class library is not compiled in the repository. The source code to the class library is. OK, that's fine. The point of fact is that there are "unversioned files that I can do nothing about." A few of us are pointing out the potential problems that occur when these unversioned files are important enough that they need to be kept around. You say you "can do nothing about" the fact that the unversioned files are important. I question whether there is really is nothing you can do. Sometimes tools gently point out that there are deficiencies elsewhere. We should not ignore them. I think the --force option is dangerous. Try it out but, in my opinion, you should not use it. I think Philip Martin's suggestion is a better solution. On 8/22/13 11:39 AM, John Maher wrote: > You digress. Not a single one of the compiled libraries lives within the > versioned directories. Please read the question before replying incorrectly. > It has nothing to do with code. It has nothing to do with the build. > Please ask for clarification if you do not understand. You gave a good > suggestion with the force option. Then you wandered off to completely > irrelevant ramblings. Should quit while you're ahead. > > -Original Message- > From: Edwin Castro [mailto:0ptikgh...@gmx.us] > Sent: Thursday, August 22, 2013 2:30 PM > To: users@subversion.apache.org > Subject: Re: Switching > > On 8/22/13 10:54 AM, John Maher wrote: >> This happens even if you do not do a build. There is a class library in one >> branch but not the other mixed with unversioned files that I can do nothing >> about. > Statements like this make me believe that build system is broken. I would > expect the svn switch like problems on nearly any SCM you use that has the > ability to switch a single working copy (or workspace, client, > what-have-you) between branches. My knee jerk reaction in situations like > this is to fix the build system. > > Are you sure there is nothing you can do? Perhaps you can suggests a simple > fix like moving the versioned class library to a location that is always > versioned. For example, instead of referencing a class library that lives in > a bin/ directory it is better to keep the class library in a lib/ directory > instead. Build output goes in the unversioned bin/ directory and versioned > resources go in the lib/ directory. > > -- > Edwin G. Castro > > > >
Re: Feature Req: ability to specify a changelist for svn merge
On 8/22/13 6:55 AM, James Hanley wrote: > ie: > svn merge -cl merge_from_trunk https://svn.somerepo.com/project/trunk > #Any items merged in are added to change list "merge_from_trunk" to > # easily differentiate from local changes that the user does not want > to check in > svn status > > M local_file_changes.txt > > --- Changelist 'merge_from_trunk': > M . > M pathhere/foo.c > M pathhere/bar.c > A +paththere/mon.h > M paththere/mon.cpp > M pathoverthere/foo > > This would then allow just the easy checkin of the merge with > svn ci -cl merge_from_trunk > > alternatively (if easier to implement) the ability to specify to svn > ci the set of files not specified as a member to a changelist. > -Jim Out of curiosity, what do you propose should happen if the merge needs to make changes to local_file_changes.txt? -- Edwin G. Castro
Re: Switching
On 8/22/13 3:00 PM, Les Mikesell wrote: >> Why can svn not, instead, simply interpret an already existing directory >> > as not a conflict? Certainly if a versioned file would overwrite an >> > unversioned file of the same name then that is a true conflict because >> > the content may differ. A directory has nicely compartmentalized units >> > of content which can be handled in a smarter way. > No, look at your logs of directory history. They aren't just > containers for whatever happens to be there, the history of adds and > deletes are there. It might be possible to make things work where it > would pretend that it created a directory keeping the history from the > repo but ignoring extraneous content, but its not what I'd expect. Directories also have "content" in the form of properties. The problem is svn doesn't have enough information to make *good* decisions about conflicts between two objects with different histories (regardless of whether the object is a file, directory, or other). Here are some examples: 1.) Two objects added in two different branches have different histories, even if they have the same name and content, causing a tree conflict on merge. 2.) Two objects with the same name where one is versioned (has history) and the other is unversioned (no history) also causes a tree conflict on merge/update/switch/etc. Because a good decision cannot be made, svn punts and requires the user to take action. -- Edwin G. Castro
Re: Switching
On 8/23/13 8:16 AM, Anders J. Munch wrote: > Edwin Castro wrote: >> I think the --force option is dangerous. Try it out but, in my opinion, >> you should not use it. > Why? Doesn't it perfectly solve the described problem? The problem with --force, as the documentation points out, is that it can make things versioned that were previously unversioned. Using a concrete example, a *.sou file that was previously unversioned might become versioned after a switch and then gets committed, accidentally, into your respository. > I had like so many others given up on switch, because cleaning up > working copies prior to the switch was annoying busywork, an > unnecessary risk (you might delete files that you wished you hadn't) > and very easily forgotten, leading to a messed up working copy. But > now I'm beginning to rethink that; I just have to remember to use > --force with every svn switch. > > I don't buy the argument about different histories: the pre-existing > directory doesn't have a subversion history, so from svn's point of > view there is no conflict. What are the real, practical problems that > you know of or foresee with svn swich --force? > When objects do not have history, then subversion is in the position to try to decide what to do with content that already exists on the filesystem. It can't make reasonable decisions because there is no base revision to use in the 3-way diff. Ultimately, the proper response is for subversion to say "I can't add the file/directory/what-have-you because there is something blocking my way". It then becomes the user's responsibility to determine what to do. Thinking in the most general sense, one solution for this scenario might work well for one individual but not another. The prescribed solution might not even work reliably every time that one individual sees this scenario. In order for subversion to do the right thing it would need to be psychic. I'm afraid subversion already takes the best possible action which is to require user intervention. -- Edwin G. Castro
Re: Switching
On 8/23/13 7:43 AM, John Maher wrote: > The question is can I bring back my working directory from a failed switch > (I'm talking undo, not resolve) so I can use the force option or must I > always use the force option to be able to switch branches? I think the mailing list has already said the *best* way to use switch is to have a clean working copy (clean out all ignored and unversioned files which is admittedly inconvenient). Some offered the opinion that the best way to use switch was to not use it at all. One way to bring back your working directory from a failed switch is to delete the conflicted directory and then svn update. If your entire working copy is "failed" then you'd need to delete the working copy and checkout again. I suppose you could try switching back to a branch that doesn't contain the directory in question, clean up, and then switch back. Use --force with caution. According to the documentation it can accidentally version previously unversioned files. -- Edwin G. Castro
Re: Switching
On 8/23/13 7:43 AM, John Maher wrote: > The files in question are settings files (think config files) and > intermediate compilet generated files. The settings files can be recreated > at any time. If they are wrong the only thing affected is the development > environment. The other files get recreated every time the code is run, plus > they never get into production. So they 1) could be recreated any time at > will with the versioned code files and 2) they will never be in production > anyway. Don't read more than what is stated otherwise you have a chance of > being wrong and wasting time. When these files get in the way of subversion performing an operation, then the sensible thing to do is to delete them. I think I heard many people voice this opinion on this mailing list. If their contents should be kept around then they should be versioned. That opinion was also voiced by the mailing list. -- Edwin G. Castro
Re: Switching
On 8/23/13 10:34 AM, Les Mikesell wrote: > I can't, off the top of my head, think of a scenario where it would be > harmful to replace an unversioned directory with a versioned instance, > leaving any unversioned local files that happen to be there alone. Leaving unversioned local files alone in a directory is not the problem. I've personally ran into scenarios where the local directory contained unversioned local files that obstruct a file that will be added by a switch/update/merge/what-have-you. If the local file's content matches the content in the repository, then I think it is safe to simply replace the unversioned local file with the versioned file from the repository. Often, the content has not been the same. It all depends on a lot of factors such as how it became unversioned, what has happened to the file while it was unversioned, etc. Replacing the content of the local file with the content in the repository looses local data. Merging the unversioned content and the versioned content usually result in poor merges (in the best case scenario) because there is no base revision to use in the 3-way merge. I've seen merges like this get committed accidentally and cause havoc. Of course, using the unversioned local content instead of merging the content from the repository could accidentally replace the entire contents of the file and this can accidentally get committed as well. Subversion needs the user's help to figure out what to do and marks these conflicts as tree conflicts.
Re: Shared branch vs single branch
On 9/23/13 1:04 PM, C M wrote: > The idea of turning over merging to them seems to be a recipe for > disaster. IMHO, merges should be performed by the individual who is most knowledgeable of the code being merged. When conflicts occur, and they WILL occur, the individual performing the merge will need to make decisions about how to resolve those conflicts. Sometimes the knowledge required is tool usage (handling tree conflicts for example) but at other times you need to understand what two diverging lines of code are trying to do in order to make a correct choice.
Re: Shared branch vs single branch
On 9/23/13 1:15 PM, BRM wrote: > "Trunk is dirty" won't save you from bad merges, it'll just make more > conflicts in your working copy as you do updates - something that > drove a colleague of mine nuts so I started working in my own branch > for that project. You also have to more frequently be doing "svn > update" on your working copy to minimize impacts of what others are doing. In my experience, working in a dirty trunk typically results in less checkins by developers. I don't consider this a good thing as their changes tend to remain uncommitted for very large periods of time (in the order of a week or so).
Re: Shared branch vs single branch
On 9/23/13 1:45 PM, Les Mikesell wrote: >> "Trunk is dirty" won't save you from bad merges, it'll just make more >> > conflicts in your working copy as you do updates - something that drove a >> > colleague of mine nuts so I started working in my own branch for that >> > project. You also have to more frequently be doing "svn update" on your >> > working copy to minimize impacts of what others are doing. > Just a matter of whether you want to resolve small conflicts as they > happen with frequent updates/commits (and maybe take advantages of > other's changes sooner rather than later), or do you want to complete > the changes in isolation so you can prove that your version was the > best and should win if there is a conflict? The isolation provided by branches can result in code that diverges greatly because the child branch is not kept in sync with its parent. Large time periods of isolation can cause some very hairy merges.
Re: ignore property not ignoring...
On 1/10/14, 2:29 PM, Edward Ned Harvey (svn4) wrote: > >> > If you upgrade the Mac client to 1.8.x, it should honor svn:global-ignores. > Easier said than done. svn ships with XCode, distributed in the App Store, > which I have the latest installed today... > But no problem. I can workaround by setting svn:ignore instead. I use svn client installed by macports. It's current version is 1.8.5. You could replace XCode's svn binaries with symlinks to the version installed by macports. XCode's svn binaries are found at /Applications/Xcode.app/Contents/Developer/usr/bin. -- Edwin
Re: ignore property not ignoring...
On 1/11/14, 6:18 AM, Edward Ned Harvey (svn4) wrote: >> From: Edwin Castro [mailto:0ptikgh...@gmx.us] >> >> I use svn client installed by macports. It's current version is 1.8.5. > > I've been down that road before. Macports is mostly reliable, but not > entirely reliable. And every time you apply some update to XCode, apple > replaces with default binaries again, which you won't know by default, until > you step into some pitfall and waste time figuring it out. And I've run into > a lot of conflicts between macports and homebrew... > > If you need 1.8, I'll agree, thanks to macports, there *is* a solution > available. But I'm choosing not to go that route... Thanks... > Sure, no problem. Then you'll need to specify svn:ignore on each directory where it applies or set it in your subversion configuration (which only applies to you) ... FYI: I don't use homebrew but https://github.com/Homebrew/homebrew/blob/master/Library/Formula/subversion.rb suggests they have subversion at 1.8.5. -- Edwin
