Re: Conflicting status report
Konstantin, the log gave me some clues that helped me fix the problem. Thanks, Cosmo
I want to know did svn_wc_entry support for path like D:\Path\To\Repo? or we must to use path like D:/Path/To/Repo
typedef struct {
PyObject_HEAD
svn_wc_adm_access_t *adm;
apr_pool_t *pool;
} AdmObject;
AdmObject admobj;
temp_pool = Pool(NULL);
if (temp_pool == NULL)
return NULL;
RUN_SVN_WITH_POOL(temp_pool, svn_wc_entry(&entry,
svn_path_canonicalize(path, temp_pool), admobj->adm, show_hidden,
temp_pool));
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
Re: svn copy between 2 repos
On Sun, Mar 11, 2012 at 7:10 AM, dhanushka ranasinghe < parakrama1...@gmail.com> wrote: > Is it possible to run svn copy between two repositorys > > Thanks > Dhanushka > Nope. If you want to bring along the history of a file or directory, you might be able to do an "svnadmin dump" on one repository and an "svnadmin load" on the other, but it's potentially quite hairy and I wouldn't recommend it. > >
Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories
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 and without hitting the network. >> >> Our VCS/CI and build slaves sit in the same lab on a fast network >> (which seems like it would be the common arrangement...) so I've never >> been particularly concerned about hitting the network - that's what it >> is designed for. And the CI knows how to do a clean checkout itself. > > > Some of us have to work through VPN's, and have relatively large checkouts. > A 100 Meg checkout is certainly not unusual in Java environments, > where bulky .war files are common, and that can be really slow over a home > DSL setup or That seems wrong or at least unnecessarily inconvenient for a CI setup. And if you are doing it by hand, why not just delete everything but your .svn directory and revert? -- Les Mikesell lesmikes...@gmail.com
Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories
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 > everything but your .svn directory and revert? Typical VCS operations should not only be possible but also easy. (And even the 'everything but .svn' part is tricky.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories
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 if you can't arrange reasonable connectivity to the repository to make clean checkouts feasible. >> And if you are doing it by hand, why not just delete >> everything but your .svn directory and revert? > > Typical VCS operations should not only be possible but also easy. > (And even the 'everything but .svn' part is tricky.) With post-1.7 versions, it shouldn't be hard at all - at least on systems where filenames starting with '.' don't expand in wildcards. But, if I know I'm going to want to return to a particular working-copy state, I just copy the whole thing locally before making the changes I may want to discard. I'd be more likely to do that to preserve a set of local changes that I wasn't sure about committing or to hold a checkpoint offline like you might in a distributed VCS, but it should work as well to have an 'already reverted' copy sitting locally when bandwidth is a concern. This isn't particularly optimal with subversion either since you end up with two full copies of everything in each instance of the working copies, but at least it gives you a choice of disk or network resources. -- Les Mikesell lesmikes...@gmail.com
Re: I want to know did svn_wc_entry support for path like D:\Path\To\Repo? or we must to use path like D:/Path/To/Repo
Yes to the second question, see svn_path.h and svn_dirent_uri.h
罗勇刚(Yonggang Luo) wrote on Sun, Mar 11, 2012 at 22:43:42 +0800:
> typedef struct {
> PyObject_HEAD
> svn_wc_adm_access_t *adm;
> apr_pool_t *pool;
> } AdmObject;
> AdmObject admobj;
>
> temp_pool = Pool(NULL);
> if (temp_pool == NULL)
> return NULL;
> RUN_SVN_WITH_POOL(temp_pool, svn_wc_entry(&entry,
> svn_path_canonicalize(path, temp_pool), admobj->adm, show_hidden,
> temp_pool));
>
>
> --
> 此致
> 礼
> 罗勇刚
> Yours
> sincerely,
> Yonggang Luo
Re: svn copy between 2 repos
Nico Kadel-Garcia wrote on Sun, Mar 11, 2012 at 11:14:41 -0400: > On Sun, Mar 11, 2012 at 7:10 AM, dhanushka ranasinghe < > parakrama1...@gmail.com> wrote: > > > Is it possible to run svn copy between two repositorys > > > > Thanks > > Dhanushka > > > Nope. If you want to bring along the history of a file or directory, you > might be able to do an "svnadmin dump" on one repository and an "svnadmin > load" on the other, but it's potentially quite hairy and I wouldn't > recommend it. 'svn merge' does work between different repositories (with some limitations, such as no merge tracking). This may be useful somehow (not only in the direct 'merge of addition' use case).
Re: path.c patch for recognizing CJK filename in OSX
Please resubmit this to dev@. See http://subversion.apache.org/patches for how to best format submissions. Thanks! Ryan Schmidt wrote on Sat, Mar 10, 2012 at 15:41:17 -0600: > > On Mar 10, 2012, at 01:31, crazia wrote: > > > The following patch enables 'svn command' to recognizing CJK filename > > correctly in OSX > > > > > > What problem happens without this patch? >
Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories
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 work if you have externals there, though. Those will be > restored if you do "svn up". For completeness, 'svn up -r BASE' will probably be useful. (And assuming the externals definitions are pegged.)
Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories
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 cleanup' can be useful. > > 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 standard, no matter what it was. In this sort of case. The lack of a "restore this working copy to the pristine state" feature does not seem fundamental to any particular Subversion approach, does it? The "CVS done right" approach, the "centralized source control with cheap branching", or any of the other features? > >> And if you are doing it by hand, why not just delete > >> everything but your .svn directory and revert? > > > > Typical VCS operations should not only be possible but also easy. > > (And even the 'everything but .svn' part is tricky.) > Easy to do, yeas, Easy to do *wrong*, even easier. The Subversion checkout contains the information for a pristine restoration, and could even include some options like recursive cleanups and "get the svn:externals, too!". > With post-1.7 versions, it shouldn't be hard at all - at least on > systems where filenames starting with '.' don't expand in wildcards. > Right: it can be written locally, and it can be written *wrong* in a lot of ways locally. > But, if I know I'm going to want to return to a particular > working-copy state, I just copy the whole thing locally before making > the changes I may want to discard. This is a pretty expensive operation in a bulky source tree, when the component checking and consistency matching is already built into tools like "svn status". > I'd be more likely to do that to > preserve a set of local changes that I wasn't sure about committing or > to hold a checkpoint offline like you might in a distributed VCS, but > it should work as well to have an 'already reverted' copy sitting > locally when bandwidth is a concern. Which is workable, but expensive in developer time and effort. > This isn't particularly optimal > with subversion either since you end up with two full copies of > everything in each instance of the working copies, but at least it > gives you a choice of disk or network resources. > 4 copies. Never forget the pristine copies in .svn/.
Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories
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 > standard, no matter what it was. In this sort of case. Mandating the use of a tool should go hand in hand with providing the necessary resources. And with subversion, one of those resources is reasonable network connectivity to the one-and-only repository (or the harder task of replicated repositories)... > The lack of a > "restore this working copy to the pristine state" feature does not seem > fundamental to any particular Subversion approach, does it? The "CVS done > right" approach, the "centralized source control with cheap branching", or > any of the other features? Not deleting random unrelated files could be considered a feature. > Right: it can be written locally, and it can be written *wrong* in a lot of > ways locally. Yes, but imagine the ways a command that removes files not under version control could go wrong. An option to 'status' that only shows the unversioned filenames so you don't have to parse them out of the larger list if you want to remove them might be nice. Doing it blindly seems a little heavy-handed. -- Les Mikesell lesmikes...@gmail.com
Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories
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 there, done that, got my wrist slapped for questioning the mandated > > standard, no matter what it was. In this sort of case. > > Mandating the use of a tool should go hand in hand with providing the > necessary resources. And with subversion, one of those resources is > reasonable network connectivity to the one-and-only repository (or the > harder task of replicated repositories)... > You'd think so, but there's a far, far distance between "necessary resources" and "optimal performance". In terms of available bandwidth. There are several thousands of projects under Subversoin at Sourceforge that will *never* have that kind of bandwidth available from that central repository, no matter what your internal network looks like. > > The lack of a > > "restore this working copy to the pristine state" feature does not seem > > fundamental to any particular Subversion approach, does it? The "CVS done > > right" approach, the "centralized source control with cheap branching", > or > > any of the other features? > > Not deleting random unrelated files could be considered a feature. > Nothing random about them, They're in the Subversion working copy, and someone specifically asked to restore that copy to a pristine state. I wouldn't suggest going down symlinks to other parts fo the operating system! > > Right: it can be written locally, and it can be written *wrong* in a lot > of > > ways locally. > > Yes, but imagine the ways a command that removes files not under > version control could go wrong. > Well, yes. But so can the "rm" command. I'm suggesting that having a *clean* implementation in Subversion itself is much safer than having the script kiddies write their own. Heck, it would eliminate a lot of my pain in writing "make clean" functions for any Subversion projects. I ran into just this situation with Nagios and BIND configurations: clearing away the debris had to be hand written.. > An option to 'status' that only shows the unversioned filenames so you > don't have to parse them out of the larger list if you want to remove > them might be nice. Doing it blindly seems a little heavy-handed. > I'm afraid of the extra processing. I've seen too many "one-off" scripts that ignored basic sanitation of the targeted file names. The obligatory XKCD quote for this problem is http://xkcd.com/327/ .
