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
> e
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
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 m
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 d
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
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
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
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
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 poi
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 dir
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
> 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
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 sw
oices 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
&
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 unvers
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 pr
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
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
18 matches
Mail list logo
