Hi,
> On 23 May 2014, at 01:08, David DL wrote:
>
> It's my understanding that if you want the process to integrate a new vendor
> drop to be sane, the update ideally should be expressed as a series of "svn
> actions" (add/update/etc.) so that history is maintained.
>
> The obvious option o
On Fri, May 23, 2014 at 08:27:08AM +0100, Andreas Stieger wrote:
> > On 23 May 2014, at 01:08, David DL wrote:
> > If you don't use the client side tools, how can you maintain in-house
> > changes against a series of vendor drops?
>
> By following the procedure: clean drops in /vendor/foo/curre
On 22.05.2014 17:05, Dan Ellis wrote:
> c:\>svn mv "c:\project_files\sandbox\foo\Bar"
> "C:\project_files\sandbox\foo\bar"
> svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup'
> for details)
> svn: E155004: Working copy 'C:\Project_files\sandbox\foo\Bar' locked.
> svn: E155004
>> If you don't use the client side tools, how can you maintain in-house changes
>>
>> against a series of vendor drops?
>
> By following the procedure: clean drops in /vendor/foo/current, tag
> releases to /vendor/foo/N (1,2,3...). The diff between them can be merged.
> Copy current to trunk once
On May 22, 2014, at 10:05 AM, Dan Ellis wrote:
> In a recent thread I've been trying to figure out the best way to deal with
> case sensitivity issues (in particular, finding out the clashing case
> sensitive path). It doesn't appear that I'll be able to solve that one
> readily, so I plan to
