On Sep 9, 2011, at 06:16, Waseem Shahzad wrote:
> What we want to same in Tortoise SVN?
If you want to learn how to do things with TortoiseSVN, you'll have to ask in a
TortoiseSVN support venue. This list is for the base Subversion software only
-- the official command line program and librarie
I have two sets of repos setup... common repos and user repos. On the machine
acting as the svn host, I have the common repos stored in /repos while the user
repos are in /home//.repos/
I'm attempting to simplify svn+ssh access such that:
svn+ssh:///Code/some_project_reposerves up
/re
On Sat, Sep 10, 2011 at 12:40:11AM +0200, Stefan Sperling wrote:
> It would help if you could present examples where elision does not
> work for you, so we can fix 'svn merge'.
The following quote from
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_client/mergeinfo.h
provides
On Fri, Sep 09, 2011 at 03:00:53PM -0400, David Carson wrote:
> OK, so let's try again. I've merged a change from another branch, which is
> a commit with a single file changed. The result is much better, but let me
> verify that I understand my results:
> - file a/b/c/foo.c shows the file change
Please keep idscussion on the mailing list by using Reply All. My reply below:
On Sep 9, 2011, at 08:17, Randy Paries wrote:
> On Thu, Sep 8, 2011 at 10:46 PM, Ryan Schmidt wrote:
>>
>>
>> svn:ignore is for ignoring unversioned files that you do not want to commit
>> to a repository.
>>
>> If
On Fri, Sep 9, 2011 at 12:38 PM, Stefan Sperling wrote:
> On Fri, Sep 09, 2011 at 12:17:15PM -0400, David Carson wrote:
> > To that end, I installed 1.7.0-rc2 with a snapshot of our repository, so
> I
> > could experiment and see for myself. I did a simple merge from one
> branch
> > to another.
> We have a repository that is seriously cluttered with the svn:mergeinfo
> property. I don't believe we ever used the buggy 1.5.x versions that added
> the property erroneously (although I could be wrong). However, due to a lax
> policy regarding where merges should occur, the property is now at
...this should be bounced, I can't seem to send to the list. I am sending this
to get a bounce so I can forward it to IT.
Sorry if this gets to the list, if it does, please ignore.
BOb
On Fri, Sep 09, 2011 at 12:17:15PM -0400, David Carson wrote:
> To that end, I installed 1.7.0-rc2 with a snapshot of our repository, so I
> could experiment and see for myself. I did a simple merge from one branch
> to another. I was disappointed to see that the same miscellaneous group of
> fil
We have a repository that is seriously cluttered with the svn:mergeinfo
property. I don't believe we ever used the buggy 1.5.x versions that added
the property erroneously (although I could be wrong). However, due to a lax
policy regarding where merges should occur, the property is now attached t
On 09/08/2011 06:21 PM, Scott Palmer wrote:
> Just tried 1.7.0RC2 and noticed that bugs with svn upgrade are still present.
>
> If you have svn:externals in the top level of your working copy they seem to
> be converted, but if those external references also use svn:externals then
> those nested w
Hi,
Von: Markus Schaber [mailto:m.scha...@3s-software.com]
> It even is more strange: If I do "svn revert --depth=files foo/bar
foo",
> then only the directory foo is reverted, and the file bar is not
restored.
This also displays no warning that foo/bar is ignored.
In addition, if I do "svn re
Markus Schaber wrote on Fri, Sep 09, 2011 at 14:20:28 +0200:
> Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> >
> > --depth=immediates properly reverts all children of the deleted
> > directory.
>
> But this also restores sibling directories to the file I want to
> restore, right?
Of cour
Hi, Daniel,
It even is more strange: If I do "svn revert --depth=files foo/bar foo",
then only the directory foo is reverted, and the file bar is not
restored.
Von: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
>
> --depth=immediates properly reverts all children of the deleted
directory.
But
--depth=immediates properly reverts all children of the deleted directory.
Markus Schaber wrote on Fri, Sep 09, 2011 at 14:06:21 +0200:
> Hi,
>
> In a working copy, "svn delete" a directory which contains files.
>
> Then do "svn revert --depth=files path/to/directory".
>
> As far as I can remem
Hi,
In a working copy, "svn delete" a directory which contains files.
Then do "svn revert --depth=files path/to/directory".
As far as I can remember, this did revert the directory as well as the
deleted files in SVN 1.6.
It only reverts the deleted directory in SVN 1.7, leaving the files
marked
On Thu, Sep 8, 2011 at 4:13 AM, Markus Schaber
wrote:
> Hi, Les,
>
> Von: Les Mikesell [mailto:lesmikes...@gmail.com]
>>
>> 2011/9/7 Thorsten Schöning :
>> >
>> >> Would it work to start the dump at the revision of the move to the
>> >> current path (without --incremental) if I'm willing to lose t
Thanks
What we want to same in Tortoise SVN?
Muchas Gracias,
Waseem Bukhari
CM - Ext: 331
From: Prabhu Gnana Sundar [mailto:prabh...@collab.net]
Sent: Friday, September 09, 2011 7:09 AM
To: users@subversion.apache.org
Subject: Re: Searching in SVN
On Friday 09 September 2011
On Friday 09 September 2011 12:04 PM, Waseem Shahzad wrote:
Hi guys!
I would like to search a file amongst 1000+ files
within a Folder. Is there any way to do this with smart way.
svn ls -R | grep
Regards
Prabhu
On Fri, Sep 09, 2011 at 09:44:06AM +0200, Johan Corveleyn wrote:
> On Fri, Sep 9, 2011 at 2:06 AM, wrote:
> > Would like to write a script to follow the history of a single
> > file, backwards, diffing the file w/it's prior version all the way
> > back to the 1st version.
> >
> > By using 'svn in
On Thu, Sep 8, 2011 at 2:13 PM, Mark Phippard wrote:
> On Thu, Sep 8, 2011 at 7:31 AM, Johan Corveleyn wrote:
>> On Mon, Sep 5, 2011 at 4:30 PM, Mark Phippard wrote:
>>> On Mon, Sep 5, 2011 at 8:51 AM, Johan Corveleyn wrote:
Is there anyone on this list able to produce binaries of 1.7.0-rc
On Fri, Sep 9, 2011 at 2:06 AM, wrote:
> Would like to write a script to follow the history of a single
> file, backwards, diffing the file w/it's prior version all the way
> back to the 1st version.
>
> By using 'svn info' to get the last chgd rev, and running 'svn
> diff -c $lastchgd_rev ...',
22 matches
Mail list logo
