Den tors 11 apr. 2024 kl 19:17 skrev Mikhail Dvorkin <
mikhail.dvor...@gmail.com>:
> I received this error when doing 'svn update':
>
> svn: E170013: Unable to connect to a repository at URL …
>
> I spent many minutes trying to find why the perfectly working server
> would not grant a connection.
On 07.03.2019 04:24, Branko Čibej wrote:
> On 07.03.2019 04:08, Marc Pawlowsky wrote:
>> Sometimes failure is an option.
>>
>> I am working inside a complex scripting environment. It would be
>> better if when svn update detects a conflict that the update did not
>> occur and that the command woul
On 07.03.2019 04:08, Marc Pawlowsky wrote:
> Sometimes failure is an option.
>
> I am working inside a complex scripting environment. It would be
> better if when svn update detects a conflict that the update did not
> occur and that the command would fail. The versioned versions of the
> file co
H.-Dirk Schmitt wrote on Tue, 09 Jan 2018 00:16 +0100:
> Hello !
>
> i missing an easy way to check a local checkout for conflicts.
>
> Currently I'm grep the output of svn status for the existence of the
> phrase „Summary of conflicts“.
> This is ugly:
> - needs LC_ALL=C ensurance
> - may break
On Sat, Apr 8, 2017 2:38 PM Johan Corveleyn wrote
>> Hm. Would that cover lines that were deleted, rather than added or
>> merely altered? That's one of my objections to a colleague's "just
>> use 'svn blame'!"
>
> I think in general it's hard to say whether you're interested in the
> deletion
On Sat, Apr 8, 2017 at 12:56 AM, Joel Polowin wrote:
> On Friday, April 7, 2017 8:16 AM, Johan Corveleyn wrote:
>> On Fri, Apr 7, 2017 at 4:50 AM, Joel Polowin wrote:
>>> In case posting to this list is sufficient... I'd like to be able
>>> to specify a line range for a file so that _svn log fil
On Friday, April 7, 2017 8:16 AM, Johan Corveleyn wrote:
> On Fri, Apr 7, 2017 at 4:50 AM, Joel Polowin wrote:
>> In case posting to this list is sufficient... I'd like to be able
>> to specify a line range for a file so that _svn log filename_ would
>> show the change log for only those lines, a
On Fri, Apr 7, 2017 at 4:50 AM, Joel Polowin wrote:
> Hi, all. This is my first post to this list, but I've been a member
> on many others.
>
> I'd like to make a feature/enhancement suggestion for svn. Would you
> please let me know how I might do that? Or of course I'd be happy if
> someone c
Marc Pawlowsky wrote on Fri, Dec 02, 2016 at 20:48:16 -0500:
> However I believe a supported, documented, and forward compatible way is
> preferable; given the volume of questions that come up when googling it
> seems to be a popular item.
>
I don't recall it ever being asked before on this lis
I had found some of the magic formulas before, which was how I was aware of
looking into the .svn directory. Thank you for the detailed responses
which I can wrap into local commands, and should be sufficient for my needs.
However I believe a supported, documented, and forward compatible way is
Marc Pawlowsky wrote on Fri, Dec 02, 2016 at 11:50:14 -0500:
> There is a lot of effort and hacks on determining what SVN database
> version is being used on the working copy. Usually resorting to
> examining the internal contents of a .svn/* file.
The incantation is:
format_number=`head -n1
16 21:43
>>>> To: users@subversion.apache.org
>>>> Subject: Re: Feature request: Restoring pristines
>>>>
>>>> On 11/9/2016 21:22, Branko Čibej wrote:
>>>>> On 08.11.2016 21:51, Stefan wrote:
>>>>>> I didn't test
Stefan Hett wrote on Thu, Nov 10, 2016 at 11:52:43 +0100:
> On 11/10/2016 8:08 AM, Cooke, Mark wrote:
> >>-Original Message-
> >>From: Stefan [mailto:luke1...@posteo.de]
> >>Sent: 09 November 2016 21:43
> >>To: users@subversion.apache.org
>
On 11/10/2016 8:08 AM, Cooke, Mark wrote:
-Original Message-
From: Stefan [mailto:luke1...@posteo.de]
Sent: 09 November 2016 21:43
To: users@subversion.apache.org
Subject: Re: Feature request: Restoring pristines
On 11/9/2016 21:22, Branko Čibej wrote:
On 08.11.2016 21:51, Stefan wrote
> -Original Message-
> From: Stefan [mailto:luke1...@posteo.de]
> Sent: 09 November 2016 21:43
> To: users@subversion.apache.org
> Subject: Re: Feature request: Restoring pristines
>
> On 11/9/2016 21:22, Branko Čibej wrote:
> > On 08.11.2016 21:51, Stefan wro
2016-11-08 17:08 GMT+01:00 Niemann, Hartmut :
> Hello!
>
> It happened to me a couple of times that subversion complains that a pristine
> file is missing from the .svn directory.
> AFAIK the only solution is to do a fresh checkout if this happens.
Several years ago I also ran into this a couple
> On Nov 8, 2016, at 10:08 AM, Niemann, Hartmut
> wrote:
>
> Hello!
>
> It happened to me a couple of times that subversion complains that a pristine
> file is missing from the .svn directory.
Why did the pristine files disappear? Who deleted them? As far as I know, it
wouldn't have been S
On 11/9/2016 21:22, Branko Čibej wrote:
> On 08.11.2016 21:51, Stefan wrote:
>> I didn't test this, but
> This is how all down-voted stackoverflow answers start. :)
>
> -- Brane
>
OK, I see. Tested and it doesn't work. ;-)
Certainly sounds like a reasonable request for an improvement to have at
le
On 08.11.2016 21:51, Stefan wrote:
> I didn't test this, but
This is how all down-voted stackoverflow answers start. :)
-- Brane
On 11/8/2016 17:08, Niemann, Hartmut wrote:
>
> Hello!
>
>
>
> It happened to me a couple of times that subversion complains that a
> pristine file is missing from the .svn directory.
>
> AFAIK the only solution is to do a fresh checkout if this happens.
>
>
>
> Would it be possible that subver
On Thu, Jul 23, 2015 at 7:16 PM Grierson, David
wrote:
> > -Original Message-
> > From: Branko Čibej [mailto:br...@wandisco.com]
> > Sent: 23 July 2015 07:59
> > To: users@subversion.apache.org
> > Subject: Re: Feature request: Save the old file when svn r
On 23.07.2015 11:15, Grierson, David wrote:
>> -Original Message-
>> From: Branko Čibej [mailto:br...@wandisco.com]
>> Sent: 23 July 2015 07:59
>> To: users@subversion.apache.org
>> Subject: Re: Feature request: Save the old file when svn revert
>>
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: 23 July 2015 07:59
> To: users@subversion.apache.org
> Subject: Re: Feature request: Save the old file when svn revert
>
> On 22.07.2015 15:51, Bert Huijben wrote:
> >
> >>
rs@subversion.apache.org
>> Subject: Re: Feature request: Save the old file when svn revert
>>
>> Markus Schaber wrote on Tue, Jul 21, 2015 at 13:01:09 +:
>>> All other commands need a --force or other explicit user decision to
>>> override user changed data, but
> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: woensdag 22 juli 2015 13:43
> To: Markus Schaber
> Cc: Grierson, David ; d...@subversion.apache.org; 牛
> 暁冬 ; users@subversion.apache.org
> Subject: Re: Feature request: Save the old
On 21 July 2015 at 11:38, Andreas Stieger wrote:
> Hello,
>
> David Grierson wrote:
>> > "svn revert" will delete the local changes and nowhere to find, which
>> > is dangerous.
>> > I suggest the default behaiver should be save the local changed
>> > file(if any) to "filename.local" and do the re
Markus Schaber wrote on Tue, Jul 21, 2015 at 13:01:09 +:
> All other commands need a --force or other explicit user decision to
> override user changed data, but the whole purpose of the "svn revert"
> command is to undo local changes - putting a --force option or
> something similar seems lik
Seems to me that stashing the before-reverted copies could go into some
"recycle bin" / "trash" folder underneath the .svn folder at the root of
the working copy. And by default, the client could clean out files
time-stamped over a month old, so it doesn't perpetually grow. Cleanup
could happen on
Guten Tag Grierson, David,
am Dienstag, 21. Juli 2015 um 17:48 schrieben Sie:
> If you don't specify prompt.
> If you do specify then you're saying one way or the other which you
> explicitly want.
That way you still force millions of users to behave differently now
because one user made a mista
On Tue, Jul 21, 2015 at 11:06:06AM +0200, OBones wrote:
> Grierson, David wrote:
> >I completely understand that the action of sending to the Recycle Bin (in
> >TortoiseSVN) is very system specific.
> >
> >To simply rename the item being reverted as $item.$backupSuffix before then
> >restoring th
> -Original Message-
> From: Thorsten Schöning [mailto:tschoen...@am-soft.de]
> Sent: 21 July 2015 17:08
> To: users@subversion.apache.org
> Subject: Re: Feature request: Save the old file when svn revert
>
> That way you still force millions of users to behave diff
> -Original Message-
> From: Thorsten Schöning [mailto:tschoen...@am-soft.de]
> Sent: 21 July 2015 16:09
> To: users@subversion.apache.org
> Subject: Re: Feature request: Save the old file when svn revert
>
> > I would very much prefer if this could be an option th
Guten Tag OBones,
am Dienstag, 21. Juli 2015 um 11:06 schrieben Sie:
> I would very much prefer if this could be an option that is not enabled
> by default.
+1
I do revert frequently while merging branches and testing things and
would hate it to have to additionally manually remove files which I
> -Original Message-
> From: Markus Schaber [mailto:m.scha...@codesys.com]
> Sent: 21 July 2015 14:01
> To: Grierson, David; d...@subversion.apache.org
> Cc: 牛暁冬; users@subversion.apache.org
> Subject: AW: Feature request: Save the old file when svn revert
> ...
> I'm not really sure what t
Apologies for the previous top-posting ... I hate Outlook sometimes.
> -Original Message-
> From: OBones [mailto:obo...@free.fr]
> Sent: 21 July 2015 10:06
> To: Grierson, David; Andreas Stieger
> Cc: 牛暁冬; users@subversion.apache.org
> Subject: Re: Feature request: Save
Grierson, David wrote:
I completely understand that the action of sending to the Recycle Bin (in
TortoiseSVN) is very system specific.
To simply rename the item being reverted as $item.$backupSuffix before then
restoring the pristine item is presumably not that system specific?
Having this fu
age-
> From: Andreas Stieger [mailto:andreas.stie...@gmx.de]
> Sent: 21 July 2015 09:38
> To: Grierson, David
> Cc: 牛暁冬; users@subversion.apache.org
> Subject: Re: Feature request: Save the old file when svn revert
>
> Hello,
>
> David Grierson wrote:
> > > &qu
Hello,
David Grierson wrote:
> > "svn revert" will delete the local changes and nowhere to find, which
> > is dangerous.
> > I suggest the default behaiver should be save the local changed
> > file(if any) to "filename.local" and do the revert.
> >
> That's actually not a bad idea ... I've been bu
That's actually not a bad idea ... I've been burnt by this one a couple of
times myself.
Probably worth raising it with the d...@subversion.apache.org list to see if
it's something that they've considered previously.
David.
--
David Grierson - SDLC Tools Specialist
Sky Broadcasting - Customer B
On 08.04.2015 20:00, Evan Driscoll wrote:
> [I typoed some keys and apparently happened to hit send while still
> typing; let's try again. Sorry for the spam.]
>
> On Fri, Apr 3, 2015 at 4:25 PM, Branko Čibej wrote:
>> Would this tell you what you need (given a checkout of 'trunk'):
>>
>> svn
[I typoed some keys and apparently happened to hit send while still
typing; let's try again. Sorry for the spam.]
On Fri, Apr 3, 2015 at 4:25 PM, Branko Čibej wrote:
> Would this tell you what you need (given a checkout of 'trunk'):
>
> svn diff --summarize ^/trunk@ .
>
> This will give you a
On Fri, Apr 3, 2015 at 4:25 PM, Branko Čibej wrote:
> Would this tell you what you need (given a checkout of 'trunk'):
>
> svn diff --summarize ^/trunk@ .
>
> This will give you a summary of the differences between your current
> working copy state and the tree in the repository at .
Sorry fo
On 04/03/15 20:27, Evan Driscoll wrote:
I'd like to put a feature request out there for a --dry-run option to 'svn up'.
There are two things that this would accomplish over 'svn stat --show-updates'.
First, it seems like a natural thing to do; in particular, 'merge'
supports --dry-run and after
On 03.04.2015 21:27, Evan Driscoll wrote:
> I'd like to put a feature request out there for a --dry-run option to 'svn
> up'.
>
> There are two things that this would accomplish over 'svn stat
> --show-updates'.
>
> First, it seems like a natural thing to do; in particular, 'merge'
> supports --d
On 06/21/2013 02:22 PM, James Hanley wrote:
> In hind site, if there was a revprop that included the version of the
> client, if an artifact issue (such as this) is discovered in the repository,
> this rev-prop can succinctly tell the administrator which version of the
> client introduced the issue
Guten Tag Aviel, Gal,
am Montag, 18. Februar 2013 um 11:14 schrieben Sie:
> any ideas and thoughts are most appreciated !
Things like file ownership are for good reasons something your OS
and/or filesystem should handle, if there's something not working for
you you should change your setup. Samba
4 (0) 1202 606473
Web:http://
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: 30 March 2012 13:06
To: Paul Coulson
Cc: users@subversion.apache.org
Subject: Re: Feature request: inhibiting checkout for tags and branches
2012/3/29 coolie :
> I have
> -Original Message-
> From: Sune Fischer [mailto:suneprogram...@gmail.com]
> Sent: vrijdag 13 april 2012 10:27
> To: users@subversion.apache.org
> Subject: Feature request: Easy tree conflick resolve mechanism
>
> Hi,
>
> In the old days the .svn folder was in every folder and resolvin
On Fri, Apr 13, 2012 at 10:27:15AM +0200, Sune Fischer wrote:
> Hi,
>
> In the old days the .svn folder was in every folder and resolving a
> tree conflict was as easy as deleting the conflicting folder and
> doing an update. This solved 90% of our issues.
> This is no longer possible as the only
2012/3/29 coolie :
> I have an inherited repo structure that has many projects with their own
> tags and branches folders.
> Users check out the whole structure as there are common lib references etc,
> but don't need to see the full contents
> of tags or branches folders, which can be massive. I w
On Thu, Mar 29, 2012 at 11:50 AM, coolie wrote:
> May have given the wrong impression here - its not access control but just
> limiting the depth of checkout to folders matching the list.
Keep in mind that the branches/tags layout in subversion is just a
convention - to subversion itself, they ar
May have given the wrong impression here - its not access control but just
limiting the depth of checkout to folders matching the list.
On Thursday, 29 March 2012 12:49:57 UTC+1, Nico Kadel-Garcia wrote:
>
> On Thu, Mar 29, 2012 at 7:19 AM, Paul Coulson wrote:
>
>> I have a legacy repo structure
On Thu, Mar 29, 2012 at 6:19 AM, Paul Coulson wrote:
> I have a legacy repo structure that has many projects with their own tags
> and branches folders.
>
> Users check out the whole structure as there are common lib references etc,
> but they don't need to see the full contents
> of tags or branc
On Thu, Mar 29, 2012 at 07:49, Nico Kadel-Garcia wrote:
> On Thu, Mar 29, 2012 at 7:19 AM, Paul Coulson wrote:
>>
>> I have a legacy repo structure that has many projects with their own tags
>> and branches folders.
>>
>> Users check out the whole structure as there are common lib references
>> e
On Thu, Mar 29, 2012 at 7:19 AM, Paul Coulson wrote:
> I have a legacy repo structure that has many projects with their own tags
> and branches folders.
>
> Users check out the whole structure as there are common lib references
> etc, but they don't need to see the full contents
> of tags or bran
On Wed, Mar 14, 2012 at 9:00 PM, Les Mikesell wrote:
> On Wed, Mar 14, 2012 at 7:29 PM, Nico Kadel-Garcia
> wrote:
> > On Wed, Mar 14, 2012 at 9:33 AM, Qazwart wrote:
> >>
> >> What if you deliver your source code *outside* of your revision control
> >> system? This is quite common for open sou
On Wed, Mar 14, 2012 at 7:29 PM, Nico Kadel-Garcia wrote:
> On Wed, Mar 14, 2012 at 9:33 AM, Qazwart wrote:
>>
>> What if you deliver your source code *outside* of your revision control
>> system? This is quite common for open source projects. If I can't trust the
>> build process to do a clean,
On Wed, Mar 14, 2012 at 9:33 AM, Qazwart wrote:
> What if you deliver your source code *outside* of your revision control
> system? This is quite common for open source projects. If I can't trust the
> build process to do a clean, I'm in trouble.
>
> What if you don't use a build process? Just to
On Wed, 14 Mar 2012 11:52:33 +, Simon Dean wrote:
...
> I use Rake and Gradle (migrated to Gradle from Maven). Rake is used for .NET
> codebases and Gradle for Java. It's very easy for files to slip through a
> "clean" task.
Actually the whole notion of a 'clean task' is misleading. Any
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: 14 March 2012 10:46
> To: 'David Weintraub'; Simon Dean
> Cc: 'Nico Kadel-Garcia'; 'Les Mikesell'; 'Andreas Krey'; 'Giulio Troccoli';
> users@s
> -Original Message-
> From: David Weintraub [mailto:qazw...@gmail.com]
> Sent: woensdag 14 maart 2012 2:14
> To: Simon Dean
> Cc: Nico Kadel-Garcia; Les Mikesell; Andreas Krey; Giulio Troccoli;
> users@subversion.apache.org
> Subject: Re: Feature request - SVN comma
On Tue, 13 Mar 2012 21:14:04 +, David Weintraub wrote:
...
> So, it's possible for someone to write a Subversion client that does
> do a "clean up".
So, what you're saying is that, because it is possible to implement
'svn cleanup' on top of the svn client libs, the official svn client
won't ge
On Mon, Mar 12, 2012 at 1:05 PM, Simon Dean
wrote:
> I suspect TortoiseSVN uses the official Subversion client code under the
> hood. There's no way they'd
> re-implement a whole SVN client from scratch.
I don't know if Tortoise uses any Subversion command line client code,
but TortoiseSVN doe
On Mon, Mar 12, 2012 at 12:32 PM, David Weintraub wrote:
> Here's why I don't think this is a feature for the Subversion project:
>
> * This is a Subversion client function and not a function of
> Subversion itself. Subversion thoughtfully publishes a Subversion API
>
So far, yes. That doesn't me
On Mon, Mar 12, 2012 at 05:11:40PM +, Simon Dean wrote:
> Not having contributed to SVN before, I don't really know how the SVN
> client(s) are implemented. How much of the code in the various Windows and
> Linux SVN command line clients (e.g. CollabNet's Windows command line client,
> Slik
> -Original Message-
> From: Simon Dean
> Sent: 12 March 2012 17:05
> To: 'David Weintraub'; Nico Kadel-Garcia
> Cc: Les Mikesell; Andreas Krey; Giulio Troccoli; users@subversion.apache.org
> Subject: RE: Feature request - SVN command to clean a working copy of all
&
kesell; Andreas Krey; Giulio Troccoli; Simon Dean;
> users@subversion.apache.org
> Subject: Re: Feature request - SVN command to clean a working copy of all
> unversioned and ignored files and directories
>
> Here's why I don't think this is a feature for the Subversion proj
Here's why I don't think this is a feature for the Subversion project:
* This is a Subversion client function and not a function of
Subversion itself. Subversion thoughtfully publishes a Subversion API
that developers can use to create their own Subversion clients. Notice
that TortoiseSVN does not
On Sun, Mar 11, 2012 at 9:19 PM, Les Mikesell wrote:
> On Sun, Mar 11, 2012 at 5:28 PM, Nico Kadel-Garcia
> wrote:
> >
> >> Subversion probably isn't the best VCS to use if you can't arrange
> >> reasonable connectivity to the repository to make clean checkouts
> >> feasible.
> >
> >
> > Been th
On Sun, Mar 11, 2012 at 5:28 PM, Nico Kadel-Garcia wrote:
>
>> Subversion probably isn't the best VCS to use if you can't arrange
>> reasonable connectivity to the repository to make clean checkouts
>> feasible.
>
>
> Been there, done that, got my wrist slapped for questioning the mandated
> stand
On Sun, Mar 11, 2012 at 2:41 PM, Les Mikesell wrote:
> On Sun, Mar 11, 2012 at 1:10 PM, Andreas Krey wrote:
> > ...
> >> That seems wrong or at least unnecessarily inconvenient for a CI
> >> setup.
> >
> > You're a bit hung up on the 'CI' token. That isn't the only situation
> > where a 'svn cle
Konstantin Kolinko wrote on Sun, Mar 11, 2012 at 01:56:45 +0400:
> If you use svn 1.7 (that is you have only ".svn" directory) it is easy to
> 1. just delete everything
> 2. do your "svn revert".
>
> The revert will restore missing files and folders from their pristine copies.
>
>
> It would not
On Sun, Mar 11, 2012 at 1:10 PM, Andreas Krey wrote:
> ...
>> That seems wrong or at least unnecessarily inconvenient for a CI
>> setup.
>
> You're a bit hung up on the 'CI' token. That isn't the only situation
> where a 'svn cleanup' can be useful.
Subversion probably isn't the best VCS to use i
On Sun, 11 Mar 2012 11:23:34 +, Les Mikesell wrote:
...
> That seems wrong or at least unnecessarily inconvenient for a CI
> setup.
You're a bit hung up on the 'CI' token. That isn't the only situation
where a 'svn cleanup' can be useful.
> And if you are doing it by hand, why not just delete
On Sun, Mar 11, 2012 at 12:15 AM, Nico Kadel-Garcia wrote:
>>
>> > Except for the part where not everyone should be forced to reinvent
>> > the wheel of 'put the sandbox in a pristine state' as in 'cd ..;
>> > rm -r $sandboxname; svn checkout -r $rev $url $sandboxname', but more
>> > efficiently a
On Sat, Mar 10, 2012 at 4:50 PM, Les Mikesell wrote:
> On Sat, Mar 10, 2012 at 2:13 PM, Andreas Krey wrote:
> >>
> > Except for the part where not everyone should be forced to reinvent
> > the wheel of 'put the sandbox in a pristine state' as in 'cd ..;
> > rm -r $sandboxname; svn checkout -r $r
2012/3/9 Simon Dean :
> Hi
>
> Are there any plans to add a command to SVN that cleans a working copy or
> path of all unversioned and/or ignored files and directories?
>
> This is a very common need for automated Continuous Integration builds where
> a working copy is reused for multiple runs of
On Sat, Mar 10, 2012 at 2:13 PM, Andreas Krey wrote:
>>
> Except for the part where not everyone should be forced to reinvent
> the wheel of 'put the sandbox in a pristine state' as in 'cd ..;
> rm -r $sandboxname; svn checkout -r $rev $url $sandboxname', but more
> efficiently and without hitting
On 3/10/2012 12:13 PM, Andreas Krey wrote:
On Sat, 10 Mar 2012 10:47:55 +, Les Mikesell wrote:
...
I'd argue that tools have no business removing any files they didn't
create unless you name them explicitly. And that complicated things
that you want a CI to automate should be scripted with
On Sat, 10 Mar 2012 10:47:55 +, Les Mikesell wrote:
...
> I'd argue that tools have no business removing any files they didn't
> create unless you name them explicitly. And that complicated things
> that you want a CI to automate should be scripted with the script
> managed in your VCS anyway
On Fri, Mar 9, 2012 at 5:25 PM, Andreas Krey wrote:
>
> If you argue that a CI/XY tool should find out for itself what files are
> not under svn control then one could argue analogously that it should
> as well bypass svn for doing updates. :-)
I'd argue that tools have no business removing any f
On Fri, 09 Mar 2012 11:53:47 +, Les Mikesell wrote:
...
> > So the CI would rely on another piece of software, SVN in this case, to
> > know what it has created in terms of files. Well, it doesn't seem right
> > to me.
>
> So how would you propose doing this across different VCS? I don't see
On Fri, Mar 9, 2012 at 2:56 PM, Simon Dean
wrote:
> Hi
>
> Are there any plans to add a command to SVN that cleans a working copy or
> path of all unversioned and/or ignored files and directories?
>
> This is a very common need for automated Continuous Integration builds where
> a working copy i
Another unconventional way of accomplishing this would be to use Bazaar's
clean-tree command. With the bzr-svn plugin installed, you should be able to
directly operate on SVN working trees:
bzr clean-tree --ignored --unknown --detritus --force
> On Fri, Mar 09, 2012 at 10:45:13AM -0700, Geoff Hoffman wrote:
> > A couple of things I find interesting... the bug tracker you linked to
> > is 3 years old and still on tigris.org. Assuming that is still the
> > valid place for tracking subversion features & bugs?
>
> The issue tracker has not
On Fri, Mar 9, 2012 at 11:34 AM, Stefan Sperling wrote:
> On Fri, Mar 09, 2012 at 10:45:13AM -0700, Geoff Hoffman wrote:
> > A couple of things I find interesting... the bug tracker you linked to
> is 3
> > years old and still on tigris.org. Assuming that is still the valid
> place
> > for tracki
On Fri, Mar 09, 2012 at 10:45:13AM -0700, Geoff Hoffman wrote:
> A couple of things I find interesting... the bug tracker you linked to is 3
> years old and still on tigris.org. Assuming that is still the valid place
> for tracking subversion features & bugs?
The issue tracker has not been migrate
2012/3/9 Giulio Troccoli :
>
>>> But maybe I'm missing something?
>> A CI implementation would have to implement it specifically each VCS as it
>> would have to call the VCS to found out what files/directories are
>> unversioned and ignored.
>
> So the CI would rely on another piece of software,
On Fri, Mar 9, 2012 at 10:24 AM, Stefan Sperling wrote:
> On Fri, Mar 09, 2012 at 01:56:34PM +, Simon Dean wrote:
> > Hi
> >
> > Are there any plans to add a command to SVN that cleans a working copy
> or path of all unversioned and/or ignored files and directories?
>
> There is a related ope
On Fri, Mar 09, 2012 at 01:56:34PM +, Simon Dean wrote:
> Hi
>
> Are there any plans to add a command to SVN that cleans a working copy or
> path of all unversioned and/or ignored files and directories?
There is a related open feature request in our issue tracker:
http://subversion.tigris
On Fri, 09 Mar 2012 14:10:39 +, Giulio Troccoli wrote:
...
> Sorry, but to me this has got nothing to do with Subversion.
'course it does. It knows which files are to be ignored, and thus
can be savely thrown away, and it does know which files are not
under version control, and thus should be
> -Original Message-
> From: Giulio Troccoli [mailto:giulio.trocc...@mediatelgroup.co.uk]
> So the CI would rely on another piece of software, SVN in this case, to know
> what it has created in terms of files. Well, it doesn't seem right to me.
With TortoiseSVN providing this functionality
On 09/03/12 15:03, Simon Dean wrote:
>> From: Giulio Troccoli [mailto:giulio.trocc...@mediatelgroup.co.uk]
>>
>> Why would the CI implement a different solution for each VCS? Those, I
>> understand, are files created during the build process, they have got nothing
>> to do with SVN or any other V
> From: Giulio Troccoli [mailto:giulio.trocc...@mediatelgroup.co.uk]
>
> Why would the CI implement a different solution for each VCS? Those, I
> understand, are files created during the build process, they have got nothing
> to do with SVN or any other VCS. And it's not a SVN specific implementat
On 09/03/12 14:35, Simon Dean wrote:
From: Giulio Troccoli [mailto:giulio.trocc...@mediatelgroup.co.uk]
Sorry, but to me this has got nothing to do with Subversion. Your CI tool is
should clean up itself.
Having said that, if someone wants to implement such feature I don't think I
would have
> From: Bob Archer [mailto:bob.arc...@amsi.com]
>
> FYI: If you are on windows the TortoiseSVN client's "Clean up" function
> allows you to delete unversioned and ignored files if you want. Also, it
> allows
> you to revert all changes when you clean up as well.
>
> BOb
>
TortoiseSVN feature i
> From: Giulio Troccoli [mailto:giulio.trocc...@mediatelgroup.co.uk]
>
> Sorry, but to me this has got nothing to do with Subversion. Your CI
> tool is should clean up itself.
>
> Having said that, if someone wants to implement such feature I don't
> think I would have anything against it. But I
> Hi
>
> Are there any plans to add a command to SVN that cleans a working copy or
> path of all unversioned and/or ignored files and directories?
>
> This is a very common need for automated Continuous Integration builds where
> a working copy is reused for multiple runs of the same build. Curr
On 09/03/12 13:56, Simon Dean wrote:
Hi
Are there any plans to add a command to SVN that cleans a working copy or path
of all unversioned and/or ignored files and directories?
This is a very common need for automated Continuous Integration builds where a
working copy is reused for multiple ru
On Fri, Mar 2, 2012 at 9:58 AM, Humm, Markus
wrote:
>
>>> We created a Junction inside D:\Test\Projekt1 named
>>> D:\Test\Projekt1\JunctionTest which points to D:\Test\Common
>>
>> Can you do this the other way around? That is, make D:\Test\Common
> the junction point, pointing to wherever your s
1 - 100 of 130 matches
Mail list logo
