Re: [SVN Users] SVN Status Command Line in 1.8 vs 1.7
Thank you Bert! On Thu, Mar 6, 2014 at 8:57 AM, Bert Huijben wrote: > The relevant change was in revision r1428637 > > > > [[ > > > > r1428637 | julianfoad | 2013-01-03 23:13:26 +0100 (do, 03 jan 2013) | 7 > lines > > > > Maintain vertical alignment of 'svn status' output with up to 8-digit > > revision numbers being shown, when '-v' and/or '-u' options are used. > > Previously the output would only remain aligned up to 6 digits; two spare > > blank columns were visible but not used. > > > > * subversion/svn/status.c > > (print_status): Allow revision numbers to use all of the existing space. > > > > Index: subversion/trunk/subversion/svn/status.c > > === > > --- subversion/trunk/subversion/svn/status.c (revision 1428636) > > +++ subversion/trunk/subversion/svn/status.c (revision > 1428637) > > @@ -377,7 +377,7 @@ print_status(const char *cwd_abspath, const char * > >SVN_ERR > > (svn_cmdline_printf(pool, > > -"%c%c%c%c%c%c%c %c %6s %6s %-12s > %s%s%s%s\n", > > +"%c%c%c%c%c%c%c %c %8s %8s %-12s > %s%s%s%s\n", > > > generate_status_code(combined_status(status)), > > generate_status_code(prop_status), > > status->wc_is_locked ? 'L' : ' ', > > @@ -396,7 +396,7 @@ print_status(const char *cwd_abspath, const char * > > } > >else > > SVN_ERR( > > - svn_cmdline_printf(pool, "%c%c%c%c%c%c%c %c %6s > %s%s%s%s\n", > > + svn_cmdline_printf(pool, "%c%c%c%c%c%c%c %c %8s %s%s%s%s\n", > > > generate_status_code(combined_status(status)), > >generate_status_code(prop_status), > >status->wc_is_locked ? 'L' : ' ', > > > > > > ]] > > > > If I read this correctly this should only change the output for revision > numbers over 6 digits. (Of course the --xml recommendation still stands) > > > > Bert > > > > *From:* Adam Contardo [mailto:aconta...@meditech.com] > *Sent:* woensdag 5 maart 2014 23:06 > *To:* Matt McCullough > *Cc:* Forest Handford; users@subversion.apache.org; David T. Murphy; SVN > Users > *Subject:* Re: [SVN Users] SVN Status Command Line in 1.8 vs 1.7 > > > > Matt, > > > > That's an interesting proposal. Do you know if there are any > pre-existing tools in M-AT that could parse up an XML file for us. > > > > Also, is the extra space character there as a place holder for a piece > of data that is depreciated in 1.8+. For example the 8 spaces (or is it > 9?) between the M and the revision number are a set of flags (1 char per > flag) representing things like lock info, whether or not there are newer > revisions on the server, etc? I'm just curious if that space char > represented a piece of data that is no longer relevant in 1.8 > > > > On Wed, Mar 5, 2014 at 9:52 AM, Matt McCullough < > matt_mccullo...@meditech.com> wrote: > > Perhaps use the --XML arg? > > > > On Wednesday, March 5, 2014, Forest Handford > wrote: > > A colleague of mine and I discovered that the location of the working > revision (working_rev) in 1.8.3 is different from 1.7.12 . We are both > using svn.exe from the TortoiseSVN package on Windows. In 1.7 he gets the > following: > > > > M 1167395 1164911 FHANDFORD > > C:\ProgramData\Meditech\MTCM.Universe\MTCM.DEVF.Ring\!AllUsers\Sys\PgmCache\Ring\PgmSource\Foc\FocZ.Subversion.C.focus > > > > In 1.8 I get: > > > > M 1167395 1164911 FHANDFORDFocZ.Subversion.C.focus > > > > > C:\ProgramData\MEDITECH\MTCM.Universe\MTCM.DEVF.Ring\!AllUsers\Sys\PgmCache\Ring > > > Notice how in 1.8 working_rev is one character further left. I took a > peak at > http://svn.apache.org/viewvc/subversion/trunk/subversion/svn/status.c?view=markupin > various revisions since march 2013. The svn_cmdline_printf() call in > print_status() appears to be consistent. working_rev also seems to be > consistently set using apr_psprintf(pool, "%ld", status->revision). We can > parse it correctly with either position, but worry that the position may > arbitrarily change in the future causing future parsing to fail. As an > example, if it moved yet another space to the left, we would lose the left > most digit. Any ideas? > > > > Thanks, > > Forest > -- > > Forest Handford, Supervisor Development, 781-774-5148 > Medical Information Technology, Inc. > Mailstop: S4W186W, MEDITECH Circle, Westwood, MA 02090 > > -- > You received this message because you are subscribed to the Google Groups > "SVN Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to svn-users-group+unsubscr...@meditech.com. > Visit this group
Re: .svn directory - safe to add files in ".svn" or ".svn/tmp"?
On 03/06/2014 08:48 PM, Andy Levy wrote: On Thu, Mar 6, 2014 at 5:44 PM, jrm wrote: Working on some tools for a development environment that will make use of SVN. There are circumstances where I want to create temporary information of my own, related to checked out versions. Rather than cluttering up the working directory with other special directories and files, I was wondering how safe it might be to make direct use of the ".svn" directory for my own purposes? Aside from the existing purposed subdirectories - would it be safe to create files in either "tmp", ".svn" proper, or a new subdirectory under ".svn"? Do not do anything in the .svn directory. That directory is exclusively for the use of the SVN working copy library and you could easily break your WC. Sure - if I overwrote something that has a genuine purpose - or created something in a location where SVN expects exactly certain files to be. But is SVN so fragile that it can't tolerate a differently named subdirectory or file under there? Or has experience taught you to treat SVN as fragile?
Re: .svn directory - safe to add files in ".svn" or ".svn/tmp"?
On 07.03.2014 17:24, jrm wrote: > > On 03/06/2014 08:48 PM, Andy Levy wrote: >> On Thu, Mar 6, 2014 at 5:44 PM, jrm wrote: >>> Working on some tools for a development environment that will make >>> use of >>> SVN. There are circumstances where I want to create temporary >>> information >>> of my own, related to checked out versions. Rather than cluttering >>> up the >>> working directory with other special directories and files, I was >>> wondering >>> how safe it might be to make direct use of the ".svn" directory for >>> my own >>> purposes? >>> >>> Aside from the existing purposed subdirectories - would it be safe >>> to create >>> files in either "tmp", ".svn" proper, or a new subdirectory under >>> ".svn"? >> Do not do anything in the .svn directory. That directory is >> exclusively for the use of the SVN working copy library and you could >> easily break your WC. > > Sure - if I overwrote something that has a genuine purpose - or created > something in a location where SVN expects exactly certain files to be. > But is SVN so fragile that it can't tolerate a differently named > subdirectory > or file under there? > > Or has experience taught you to treat SVN as fragile? It's not a question of SVN being fragile or not. The .svn/ directory is private to Subversion and you're not allowed to fiddle with it. We've been saying this loudly over and over again for 10+ years. Of course, every now and then someone comes along and says, "sure, but that doesn't apply to /me/". The result are tools that break with the next Subversion upgrade, or that break Subversion when it's upgraded. No-one can stop you from messing with .svn/, but if you do, please don't report here when something breaks. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: .svn directory - safe to add files in ".svn" or ".svn/tmp"?
On 3/7/14, 8:24 AM, jrm wrote: >> Do not do anything in the .svn directory. That directory is >> exclusively for the use of the SVN working copy library and you could >> easily break your WC. > > Sure - if I overwrote something that has a genuine purpose - or created > something in a location where SVN expects exactly certain files to be. > But is SVN so fragile that it can't tolerate a differently named > subdirectory > or file under there? > > Or has experience taught you to treat SVN as fragile? The proper solution is to use your own directory alongside .svn. Could you put it under .svn, it's likely you could do it and it would work. I wouldn't use tmp because while Subversion should be pretty tolerant to this there's no guarantee we won't make changes that would make it less so in the future. While we may take reasonable steps to avoid problems, we also have a completely reasonable belief that everything under .svn is for the exclusive use of Subversion and should only be modified using the methods that we use. For example. It's perfectly reasonable for us to take out an exclusive lock on the wc, look at the files in tmp, generate a new name based on that and then assume that some other program hasn't also decided to use that same name because we have an exclusive lock.
Re: .svn directory - safe to add files in ".svn" or ".svn/tmp"?
Branko Čibej writes: > No-one can stop you from messing with .svn/, but if you do, please don't > report here when something breaks. Running 'svn cleanup' removes everything in .svn/tmp. Upgrading from 1.6 to 1.7 removes the entire .svn directory from every directory except the working copy root. A future upgrade might remove the .svn directory from directory externals. A future upgrade might move the .svn directory outside the working copy root. A future upgrade might make .svn into a file. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: [SVN Users] SVN Status Command Line in 1.8 vs 1.7
Sweet, thanks Bert. This will certainly save us a substantial amount of time and energy. On Fri, Mar 7, 2014 at 8:51 AM, Forest Handford wrote: > Thank you Bert! > > > On Thu, Mar 6, 2014 at 8:57 AM, Bert Huijben wrote: > >> The relevant change was in revision r1428637 >> >> >> >> [[ >> >> >> >> r1428637 | julianfoad | 2013-01-03 23:13:26 +0100 (do, 03 jan 2013) | 7 >> lines >> >> >> >> Maintain vertical alignment of 'svn status' output with up to 8-digit >> >> revision numbers being shown, when '-v' and/or '-u' options are used. >> >> Previously the output would only remain aligned up to 6 digits; two spare >> >> blank columns were visible but not used. >> >> >> >> * subversion/svn/status.c >> >> (print_status): Allow revision numbers to use all of the existing space. >> >> >> >> Index: subversion/trunk/subversion/svn/status.c >> >> === >> >> --- subversion/trunk/subversion/svn/status.c (revision 1428636) >> >> +++ subversion/trunk/subversion/svn/status.c (revision >> 1428637) >> >> @@ -377,7 +377,7 @@ print_status(const char *cwd_abspath, const char * >> >>SVN_ERR >> >> (svn_cmdline_printf(pool, >> >> -"%c%c%c%c%c%c%c %c %6s %6s %-12s >> %s%s%s%s\n", >> >> +"%c%c%c%c%c%c%c %c %8s %8s %-12s >> %s%s%s%s\n", >> >> >> >> generate_status_code(combined_status(status)), >> >> generate_status_code(prop_status), >> >> status->wc_is_locked ? 'L' : ' ', >> >> @@ -396,7 +396,7 @@ print_status(const char *cwd_abspath, const char * >> >> } >> >>else >> >> SVN_ERR( >> >> - svn_cmdline_printf(pool, "%c%c%c%c%c%c%c %c %6s >> %s%s%s%s\n", >> >> + svn_cmdline_printf(pool, "%c%c%c%c%c%c%c %c %8s %s%s%s%s\n", >> >> >> generate_status_code(combined_status(status)), >> >>generate_status_code(prop_status), >> >>status->wc_is_locked ? 'L' : ' ', >> >> >> >> >> >> ]] >> >> >> >> If I read this correctly this should only change the output for revision >> numbers over 6 digits. (Of course the --xml recommendation still stands) >> >> >> >> Bert >> >> >> >> *From:* Adam Contardo [mailto:aconta...@meditech.com] >> *Sent:* woensdag 5 maart 2014 23:06 >> *To:* Matt McCullough >> *Cc:* Forest Handford; users@subversion.apache.org; David T. Murphy; SVN >> Users >> *Subject:* Re: [SVN Users] SVN Status Command Line in 1.8 vs 1.7 >> >> >> >> Matt, >> >> >> >> That's an interesting proposal. Do you know if there are any >> pre-existing tools in M-AT that could parse up an XML file for us. >> >> >> >> Also, is the extra space character there as a place holder for a >> piece of data that is depreciated in 1.8+. For example the 8 spaces (or is >> it 9?) between the M and the revision number are a set of flags (1 char per >> flag) representing things like lock info, whether or not there are newer >> revisions on the server, etc? I'm just curious if that space char >> represented a piece of data that is no longer relevant in 1.8 >> >> >> >> On Wed, Mar 5, 2014 at 9:52 AM, Matt McCullough < >> matt_mccullo...@meditech.com> wrote: >> >> Perhaps use the --XML arg? >> >> >> >> On Wednesday, March 5, 2014, Forest Handford >> wrote: >> >> A colleague of mine and I discovered that the location of the working >> revision (working_rev) in 1.8.3 is different from 1.7.12 . We are both >> using svn.exe from the TortoiseSVN package on Windows. In 1.7 he gets the >> following: >> >> >> >> M 1167395 1164911 FHANDFORD >> >> C:\ProgramData\Meditech\MTCM.Universe\MTCM.DEVF.Ring\!AllUsers\Sys\PgmCache\Ring\PgmSource\Foc\FocZ.Subversion.C.focus >> >> >> >> In 1.8 I get: >> >> >> >> M 1167395 1164911 FHANDFORDFocZ.Subversion.C.focus >> >> >> >> >> C:\ProgramData\MEDITECH\MTCM.Universe\MTCM.DEVF.Ring\!AllUsers\Sys\PgmCache\Ring >> >> >> Notice how in 1.8 working_rev is one character further left. I took a >> peak at >> http://svn.apache.org/viewvc/subversion/trunk/subversion/svn/status.c?view=markupin >> various revisions since march 2013. The svn_cmdline_printf() call in >> print_status() appears to be consistent. working_rev also seems to be >> consistently set using apr_psprintf(pool, "%ld", status->revision). We can >> parse it correctly with either position, but worry that the position may >> arbitrarily change in the future causing future parsing to fail. As an >> example, if it moved yet another space to the left, we would lose the left >> most digit. Any ideas? >> >> >> >> Thanks, >> >> Forest >> -- >> >> Forest Handford, Supervisor Development, 781-774-5148 >> Medical Inf
[BUG][All versions][svn merge --reintegrate] doesn't work on ra_svn
Hello, all!
The bug was detected first time on:
--
dev: {501} svn --version
svn, version 1.5.2 (r32768)
compiled Oct 10 2012, 09:39:49
Copyright (C) 2000-2008 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
--
This bug affects "svn log" too but I have not found the proof sequence. Thus
I'm reporting "merge --reintegrate" only.
The last time was testet on WANdisco distro under Windows. There are full log.
NOTE: the same log works via ra_local or "http://"; URLs without troubles.
D:\src>sc create svn binpath= "d:\wandisco\subversion\svnserve.exe --service -r
d:\svntest" displayname= "svn serve" depend= Tcpip start= auto
[SC] CreateService SUCCESS
D:\src>mkdir \svntest
D:\src>svnadmin create d:\svntest
$ diff -u /cygdrive/d/svntest/conf/authz.old /cygdrive/d/svntest/conf/authz
--- /cygdrive/d/svntest/conf/authz.old 2014-03-07 21:25:53.40625 +0400
+++ /cygdrive/d/svntest/conf/authz 2014-03-07 21:41:18.015625000 +0400
@@ -30,3 +30,5 @@
# [repository:/baz/fuz]
# @harry_and_sally = rw
# * = r
+[/]
+svntest = rw
$ diff -u /cygdrive/d/svntest/conf/passwd.old /cygdrive/d/svntest/conf/passwd
--- /cygdrive/d/svntest/conf/passwd.old 2014-03-07 21:25:53.40625 +0400
+++ /cygdrive/d/svntest/conf/passwd 2014-03-07 21:28:00.796875000 +0400
@@ -6,3 +6,4 @@
[users]
# harry = harryssecret
# sally = sallyssecret
+svntest = svntest
$ diff -u /cygdrive/d/svntest/conf/svnserve.conf.old
/cygdrive/d/svntest/conf/svnserve.conf
--- /cygdrive/d/svntest/conf/svnserve.conf.old 2014-03-07 21:25:53.40625
+0400
+++ /cygdrive/d/svntest/conf/svnserve.conf 2014-03-07 21:39:49.03125
+0400
@@ -16,15 +16,15 @@
### The sample settings below are the defaults and specify that anonymous
### users have read-only access to the repository, while authenticated
### users have read and write access to the repository.
-# anon-access = read
-# auth-access = write
+anon-access = read
+auth-access = write
### The password-db option controls the location of the password
### database file. Unless you specify a path starting with a /,
### the file's location is relative to the directory containing
### this configuration file.
### If SASL is enabled (see below), this file will NOT be used.
### Uncomment the line below to use the default password file.
-# password-db = passwd
+password-db = passwd
### The authz-db option controls the location of the authorization
### rules for path-based access control. Unless you specify a path
### starting with a /, the file's location is relative to the
@@ -33,7 +33,7 @@
### file in a Subversion repository. If you don't specify an authz-db,
### no path-based access control is done.
### Uncomment the line below to use the default authorization file.
-# authz-db = authz
+authz-db = authz
### The groups-db option controls the location of the groups file.
### Unless you specify a path starting with a /, the file's location is
### relative to the directory containing this file. The specified path
@@ -44,7 +44,7 @@
### If two repositories have the same authentication realm, they should
### have the same password database, and vice versa. The default realm
### is repository's uuid.
-# realm = My First Repository
+realm = svntest
### The force-username-case option causes svnserve to case-normalize
### usernames before comparing them against the authorization rules in the
### authz-db file configured above. Valid values are "upper" (to upper-
D:\src>mkdir t
D:\src>cd t
D:\src\t>mkdir trunk branches tags
D:\src\t>cd trunk
D:\src\t\trunk>echo "1 2" >test.txt
D:\src\t\trunk>cd ..
D:\src\t>svn import --username=svntest svn://localhost/t -m "initial"
Authentication realm: svntest
Password for 'svntest': ***
Adding branches
Adding tags
Adding trunk
Adding trunk\test.txt
Committed revision 1.
D:\src\t>svn list svn://localhost/t
branches/
tags/
trunk/
D:\src\t>svn copy svn://localhost/t/trunk svn://localhost/t/branches/b -m "make
branch"
Committed revision 2.
D:\src\t>cd ..
D:\src>svn checkout svn://localhost/t/trunk t
At\test.txt
Checked out revision 2.
D:\src>svn checkout svn://localhost/t/branches/b
Ab\test.txt
Checked out revision 2.
D:\src>cd b
D:\src\b>echo "33 44" >>test.txt
D:\src\b>cd ..\t
D:\src\t>echo "55 66
tigris.org down?
Trying to access the issue tracker, but subversion.tigris.org is dropping connections.
Re: tigris.org down?
On 3/7/14, 2:46 PM, Kyle Sluder wrote: > Trying to access the issue tracker, but subversion.tigris.org is > dropping connections. It's working for me now.
Re: tigris.org down?
On Fri, Mar 7, 2014, at 03:01 PM, Ben Reser wrote: > On 3/7/14, 2:46 PM, Kyle Sluder wrote: > > Trying to access the issue tracker, but subversion.tigris.org is > > dropping connections. > > It's working for me now. > Me too. Thanks, all. I'll keep quiet if it hiccups again ;-) --Kyle Sluder
Re: .svn directory - safe to add files in ".svn" or ".svn/tmp"?
On Fri, Mar 7, 2014 at 11:24 AM, jrm wrote: > Sure - if I overwrote something that has a genuine purpose - or created > something in a location where SVN expects exactly certain files to be. > But is SVN so fragile that it can't tolerate a differently named > subdirectory > or file under there? But I made sure the safety was on! I was aiming at the apple, not his head! I've worked as the root user, I know how to it safely! If I get in a car accident, I'd rather get killed outright than merely left in a coma because I wore the seat belet! I'm always careful not to touch the 3rd rail when I walk across electric train tracks! It' s quite that dangerous, but it's safer to Just Don't Do That(tm). If you need to leave a flag file around, mention it in .gitignore and leave it in a visible location.
