RE: Archiving Projects (End-Of-Life)

[Giulio Troccoli]

>


Linedata Limited
Registered Office: 85 Gracechurch St., London, EC3V 0AA
Registered in England and Wales No 3475006 VAT Reg No 710 3140 03

-Original Message-


> From: Johan Corveleyn [mailto:jcor...@gmail.com]
> Sent: 13 December 2010 20:04
> To: users@subversion.apache.org
> Subject: Archiving Projects (End-Of-Life)
>
> Hi,
>
> I'm wondering if there is a (de-facto) standard way of "end-of-lifing"
> projects in an SVN repository, or any suggestions for this
> from other users on this list ...
>
> With End-Of-Life I mean there will be no further maintenance
> on that project, no more development, no more releases or
> patches, no more users. It's really dead. But sometimes one
> might want to take a look at the old code, check out its
> history, maybe even resurrect it, ...
> I would like to get those projects out of sight, so it's more
> clear what the active projects are. (I'm not talking about
> "obliterating", to reclaim disk space or anything like that,
> quite the contrary: I want to have them still available, just
> ... less visible).
>
> I know I could just "svn rm" them, but some of the "project owners"
> feel a little bit uneasy about that. They consider it
> "probable" that they will need to take another look at them
> sometime in the future.
> And as we all know, it's not so easy to find a deleted
> file/directory/project again (to find out what the latest
> revision was in which the project still existed).
>
> My repository is currently structured as:
>
> trunk
>   \--project1
>   \--project2
>   \--...
> branches
> tags
>
> But I think the question is more or less the same if it's
> structured in the other standard way (projects/TTB).
>
> Currently I have two options in mind:
> - Move the EOL'ed projects to a new directory "archive", a new "root"
> directory next to TTB.
> - Move the EOL'ed projects to a tag (maybe also in an "archive"
> subdirectory, under tags). If it ever needs to be
> resurrected, it can be easily copied from that tag.
>
> Thoughts? Other ideas? Pros and cons?

Maybe I'm missing something, but since you have a tags directory I guess you 
did tag your last release of the project. So why not just simply (svn) delete 
the project from trunk? The whole history is preserved in the latest tag for 
that project, is it not?

Giulio

Re: Update to revision and externals

[Norbert Unterberg]

2010/12/14 Ryan Schmidt :
> On Dec 13, 2010, at 04:27, Norbert Unterberg wrote:
>
>> We have a project that contains a few svn:externals which point into
>> the same repository (using ../ or ^/ syntax).
>> Problem is that when we need to go back in time with the project for
>> some reason and do an TSVN --> Update to revision ... then the
>> externals are still updated to their HEAD revision and not to the
>> revision that was given in the update command.
>
> only if you've defined your externals without a revision argument. You 
> should always define your externals with a revision argument, a peg revision 
> in fact, so that when you update to previous versions of your project, your 
> externals go back as well. This also gives you concrete times at which you 
> update your externals to new versions of that external software, instead of 
> having them auto-update, as it were, and possibly break your project in the 
> process.

I will think about that. The problem is that in our case the external
is not really "external" but points to a different folder in the same
active project (please no discussion here why that is so). So normally
we want to work with "trunk" of both projects without daily
modification to the externals property. I just thought there might be
a switch to make "svn up -r" a real time machine.

Norbert

RE: Archiving Projects (End-Of-Life)

[Cooke, Mark]

> -Original Message-
> From: Johan Corveleyn [mailto:jcor...@gmail.com] 
> Sent: 13 December 2010 20:04
> To: users@subversion.apache.org
> Subject: Archiving Projects (End-Of-Life)
> 
> Hi,
> 
> I'm wondering if there is a (de-facto) standard way of "end-of-lifing"
> projects in an SVN repository, or any suggestions for this from other
> users on this list ...
> 
> With End-Of-Life I mean there will be no further maintenance on that
> project, no more development, no more releases or patches, no more
> users. It's really dead. But sometimes one might want to take a look
> at the old code, check out its history, maybe even resurrect it, ...
> I would like to get those projects out of sight, so it's more clear
> what the active projects are. (I'm not talking about "obliterating",
> to reclaim disk space or anything like that, quite the contrary: I
> want to have them still available, just ... less visible).
> 
> I know I could just "svn rm" them, but some of the "project owners"
> feel a little bit uneasy about that. They consider it "probable" that
> they will need to take another look at them sometime in the future.
> And as we all know, it's not so easy to find a deleted
> file/directory/project again (to find out what the latest revision was
> in which the project still existed).
> 
> My repository is currently structured as:
> 
> trunk
>   \--project1
>   \--project2
>   \--...
> branches
> tags
> 
> But I think the question is more or less the same if it's structured
> in the other standard way (projects/TTB).
> 
> Currently I have two options in mind:
> - Move the EOL'ed projects to a new directory "archive", a new "root"
> directory next to TTB.
> - Move the EOL'ed projects to a tag (maybe also in an "archive"
> subdirectory, under tags). If it ever needs to be resurrected, it can
> be easily copied from that tag.
> 
> Thoughts? Other ideas? Pros and cons?
> 
I use separate repos (using parent path) for all projects unless closely
related, and this is one of the main reasons why I do so.  A little bit
of extra work when creating new projects is a lot simpler than
dumpfiltering projects out late in the lifecycle.

I'd be interested in any strong arguments for using one repo over many!

~ mark c

Re: Archiving Projects (End-Of-Life)

[Ulrich Eckhardt]

On Tuesday 14 December 2010, Cooke, Mark wrote:
> I'd be interested in any strong arguments for using one repo over many!

You don't need svnadmin to create a new project.

That was simple! :'D

Uli

-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/


**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht 
verantwortlich.
**

RE: Archiving Projects (End-Of-Life)

[Cooke, Mark]

> On Tuesday 14 December 2010, Cooke, Mark wrote:
> > I'd be interested in any strong arguments for using one 
> > repo over many!
> 
> -Original Message-
> From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com] 
> Sent: 14 December 2010 10:53
> To: users@subversion.apache.org
> Subject: Re: Archiving Projects (End-Of-Life)
> 
> You don't need svnadmin to create a new project.
> 
> That was simple! :'D
> 
> Uli
> 
...but I don't see that as a problem for us, it's just a little pain
occasionally for a big gain in the end.

Plus, for us, we usually have linked Trac environments, so that needs to
be created as well.  In fact, having linked trac projects is another
reason why I like the lack of revision number churn caused by unrelated
projects.

~ mark c

Re: Archiving Projects (End-Of-Life)

[Johan Corveleyn]

On Tue, Dec 14, 2010 at 11:58 AM, Cooke, Mark  wrote:
>> On Tuesday 14 December 2010, Cooke, Mark wrote:
>> > I'd be interested in any strong arguments for using one
>> > repo over many!
>>
>> -Original Message-
>> From: Ulrich Eckhardt [mailto:ulrich.eckha...@dominolaser.com]
>> Sent: 14 December 2010 10:53
>> To: users@subversion.apache.org
>> Subject: Re: Archiving Projects (End-Of-Life)
>>
>> You don't need svnadmin to create a new project.
>>
>> That was simple! :'D
>>
>> Uli
>>
> ...but I don't see that as a problem for us, it's just a little pain
> occasionally for a big gain in the end.
>
> Plus, for us, we usually have linked Trac environments, so that needs to
> be created as well.  In fact, having linked trac projects is another
> reason why I like the lack of revision number churn caused by unrelated
> projects.
>
> ~ mark c
>

In our case, code sometimes migrates from one project to another (the
projects are closely related, or put another way: there are a lot of
dependencies among them).

For instance: we have a "common" project, with the common utilities
used by other projects. Sometimes, some new utility code is written in
one of the projects (starts out as being useful for that single
project), and after a while, they see that it could be useful for
other projects as well. So the stuff is moved to the common project,
without losing history etc.

We don't care about revision number churn ...

-- 
Johan

Re: Archiving Projects (End-Of-Life)

[Nick Stolwijk]

You cannot easily refactor code into seperate modules, used by
multiple projects, with keeping of history.

Another easy one. ;)

Hth,

Nick Stolwijk
~Senior Java Developer~

iPROFS
Wagenweg 208
2012 NM Haarlem
T +31 23 547 6369
F +31 23 547 6370
I www.iprofs.nl



On Tue, Dec 14, 2010 at 11:02 AM, Cooke, Mark  wrote:
>> -Original Message-
>> From: Johan Corveleyn [mailto:jcor...@gmail.com]
>> Sent: 13 December 2010 20:04
>> To: users@subversion.apache.org
>> Subject: Archiving Projects (End-Of-Life)
>>
>> Hi,
>>
>> I'm wondering if there is a (de-facto) standard way of "end-of-lifing"
>> projects in an SVN repository, or any suggestions for this from other
>> users on this list ...
>>
>> With End-Of-Life I mean there will be no further maintenance on that
>> project, no more development, no more releases or patches, no more
>> users. It's really dead. But sometimes one might want to take a look
>> at the old code, check out its history, maybe even resurrect it, ...
>> I would like to get those projects out of sight, so it's more clear
>> what the active projects are. (I'm not talking about "obliterating",
>> to reclaim disk space or anything like that, quite the contrary: I
>> want to have them still available, just ... less visible).
>>
>> I know I could just "svn rm" them, but some of the "project owners"
>> feel a little bit uneasy about that. They consider it "probable" that
>> they will need to take another look at them sometime in the future.
>> And as we all know, it's not so easy to find a deleted
>> file/directory/project again (to find out what the latest revision was
>> in which the project still existed).
>>
>> My repository is currently structured as:
>>
>> trunk
>>   \--project1
>>   \--project2
>>   \--...
>> branches
>> tags
>>
>> But I think the question is more or less the same if it's structured
>> in the other standard way (projects/TTB).
>>
>> Currently I have two options in mind:
>> - Move the EOL'ed projects to a new directory "archive", a new "root"
>> directory next to TTB.
>> - Move the EOL'ed projects to a tag (maybe also in an "archive"
>> subdirectory, under tags). If it ever needs to be resurrected, it can
>> be easily copied from that tag.
>>
>> Thoughts? Other ideas? Pros and cons?
>>
> I use separate repos (using parent path) for all projects unless closely
> related, and this is one of the main reasons why I do so.  A little bit
> of extra work when creating new projects is a lot simpler than
> dumpfiltering projects out late in the lifecycle.
>
> I'd be interested in any strong arguments for using one repo over many!
>
> ~ mark c
>

Re: Archiving Projects (End-Of-Life)

[Thorsten Schöning]

Guten Tag Nick Stolwijk,
am Dienstag, 14. Dezember 2010 um 12:03 schrieben Sie:

> Another easy one. ;)

Using separate repositories for projects makes access control a lot
easier and safer: Depending on using svnserve, one has the chance to
use different instances for svnserve on different ports for different
projects. We for example have divided our projects into source and
binary projects, one for internal, one for internal and external use,
with (nearly?) no chance that an external user can gain access to the
internal repositories or any other port/service running on the
svn-server.

In one repository created users can't accidently gain access to
repositories which they shouldn't get access on.

Hooks can be managed on a per project base and you don't need to write
UML for hooks just because you have 20 projects with different needs
pre or post a commit.

Maintenance if some problem occurs which needs dumping and loading or
stuff like that is easier and faster.

First page in WebSVN is descriptive to users out of the box.

It's as always, if to decide what to centralize and what not...

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoen...@am-soft.de
Web: http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow

Re: svnsync failure when syncing with a repository that used ISO-8859-1 for log messages

[Christopher Dobbs]

Danny Trebbien  gmail.com> writes:

> 
> > I must be missing something here, is this patch applied to the current SVN
source?
> >
> > I have downloaded SVN 1.6.15 source from Tigris.org, and cant find the
changes in the source. Also this
> patch is applied to a file : subversion/svnsync/sync.c but in my downloaded
source there is only a file
> main.c in the svnsync directory.
> >
> > We are for the moment stuck with this UTF-8 problem in one of our svn:ignore
properties, and cant proceed
> with seting up this sync, so any pointers are welcome!
> >
> > Geir
> 
> Hi Geir,
> 
Hi Danny,
I am working with Geir Engebakken on this and we understand you won't release
the patch now until 1.7.x - That's fine but I wanted to try out the patch myself
now so I tried to run it in and it is looking for sync.c and sync.h which dont
seem to exist in my source tree. I have downloaded the latest version 1.6.15
??

Any help is appreciated!!

-Chris

> No, this patch has not yet been applied to SVN trunk.  I have been
> working with some of the Subversion devs (Daniel Shahaf, Gavin, and
> Julian) to fix this problem in a series of commits.  We are currently
> working on a patch to libsvn_subr-1 upon which my svnsync patch
> depends, and it is very close to being applied to trunk, but hasn't
> been committed yet.  I suspect that when all is said and done, the
> version of Subversion that will contain the patch will be in the 1.7.x
> series.
> 
> In the meantime, the way that I got past the issue with syncing the
> GNU Nano repository was to compile Subversion with the above patch
> (the one that always recodes revprops into ISO-8859-1), use the
> newly-compiled `svnsync` to sync the repository, revert to a standard
> build of `svnsync`, and use `svnsync copy-revprops` to "go back" and
> fix the revprops of revisions that really use UTF-8.  The idea here is
> to pick an encoding (ISO-8859-1) that is partially compatible with
> UTF-8 and in which any sequence of bytes is a "valid" string in that
> encoding.  After syncing the entire repository in that encoding, any
> revprops that are encoded in UTF-8 will be incorrect.  But, after
> identifying specific revisions or ranges of revisions where revprops
> are encoded in UTF-8, you "go back" and use the standard `svnsync
> copy-revprops` for each of these revisions to correct them.
> 
> Hope that helps,
> 
> Danny
> 
> 

Restoring from old backup

[Mauro Condarelli]

 Hi,
This should be a FAQ, but I didn't find a proper answer, so here I am.

I suffered a crash in my SVN server machine.
I had a slightly old version of the repository on my backup disks.
I have a few modified working copies.

I restored the server and the repository.
All *seemed* ok, but, unfortunately, the latest version of saved repo 
was 99, while the "current" in my working copies is 104.


Now Subclipse (and TortoiseSVN) refuse to Submit my latest copy because 
"version 104 does not exist".


I understand I lost a few steps in the program history, but I would like 
to salvage as much as possible.

What is the right incantation to achieve that?

I would rather not checkout a fresh copy, move all changes to it and 
submit that, if possible, because it is too error-prone.


Can someone suggest a course of action?

TiA
Mauro

Re: Restoring from old backup

[Andy Levy]

On Tue, Dec 14, 2010 at 09:34, Mauro Condarelli  wrote:
>  Hi,
> This should be a FAQ, but I didn't find a proper answer, so here I am.
>
> I suffered a crash in my SVN server machine.
> I had a slightly old version of the repository on my backup disks.
> I have a few modified working copies.
>
> I restored the server and the repository.
> All *seemed* ok, but, unfortunately, the latest version of saved repo was
> 99, while the "current" in my working copies is 104.
>
> Now Subclipse (and TortoiseSVN) refuse to Submit my latest copy because
> "version 104 does not exist".
>
> I understand I lost a few steps in the program history, but I would like to
> salvage as much as possible.
> What is the right incantation to achieve that?
>
> I would rather not checkout a fresh copy, move all changes to it and submit
> that, if possible, because it is too error-prone.

That is what you will have to do.

Subversion version on server

[K F]

This is just a simple question that I can't find the answer to. How do I go 
about finding out what version of subversion (e.g. 1.6.#) is on the server. The 
svn help doesn't give that type of information and there is no 'about' that 
usually has that info.

Thanks,
Rich




  

Re: Subversion version on server

[vishwajeet singh]

On Tue, Dec 14, 2010 at 8:49 PM, K F  wrote:

> This is just a simple question that I can't find the answer to. How do I go
> about finding out what version of subversion (e.g. 1.6.#) is on the server.
> The svn help doesn't give that type of information and there is no 'about'
> that usually has that info.
>

on command prompt type *svn --version*  and you will get the required info



>
> Thanks,
> Rich
>
>
>


-- 
Vishwajeet Singh
+91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com
Twitter: http://twitter.com/vishwajeets | LinkedIn:
http://www.linkedin.com/in/singhvishwajeet

RE: Subversion version on server

[Ludwig, Michael]

> on command prompt type svn --version  and you will get the required info

That's for the client.

The OP asked how to get the version of the server from the clientside.
(So without access to the serverside.)

I naively tried the following, but it doesn't reveal the version info:

l...@hrswks006: ~ > echo version | nc svn.our-server.dev 3690
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops 
depth log-revprops partial-replay ) ) ) 

-- 
Michael

Re: Restoring from old backup

[Les Mikesell]

On 12/14/2010 9:09 AM, Andy Levy wrote:

On Tue, Dec 14, 2010 at 09:34, Mauro Condarelli  wrote:

  Hi,
This should be a FAQ, but I didn't find a proper answer, so here I am.

I suffered a crash in my SVN server machine.
I had a slightly old version of the repository on my backup disks.
I have a few modified working copies.

I restored the server and the repository.
All *seemed* ok, but, unfortunately, the latest version of saved repo was
99, while the "current" in my working copies is 104.

Now Subclipse (and TortoiseSVN) refuse to Submit my latest copy because
"version 104 does not exist".

I understand I lost a few steps in the program history, but I would like to
salvage as much as possible.
What is the right incantation to achieve that?

I would rather not checkout a fresh copy, move all changes to it and submit
that, if possible, because it is too error-prone.


That is what you will have to do.


I'm not 100% sure, but I think 'rsync --delete -avC source dest' would 
copy the existing checked-out working copy that you want to become the 
new HEAD on top of a tree checked out from your restored backup.  The 
'-C' option is shorthand for a bunch of excludes that should keep it 
from copying over the metadata under .svn directories along with things 
that are typically build results.


--
  Les Mikesell
   lesmikes...@gmail.com

Re: Restoring from old backup

[Thorsten Schöning]

Guten Tag Mauro Condarelli,
am Dienstag, 14. Dezember 2010 um 15:34 schrieben Sie:

> I would rather not checkout a fresh copy, move all changes to it and
> submit that, if possible, because it is too error-prone.

Some weeks ago I had the same situation, two times within one week,
and I didn't find any other suitable solution.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoen...@am-soft.de
Web: http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow

Re: Restoring from old backup

[Stefan Sperling]

On Tue, Dec 14, 2010 at 04:35:59PM +0100, Thorsten Schöning wrote:
> Guten Tag Mauro Condarelli,
> am Dienstag, 14. Dezember 2010 um 15:34 schrieben Sie:
> 
> > I would rather not checkout a fresh copy, move all changes to it and
> > submit that, if possible, because it is too error-prone.
> 
> Some weeks ago I had the same situation, two times within one week,
> and I didn't find any other suitable solution.

The best approach is to be prepared and use a good backup strategy.

>From the post-commit hook, create an incremental dump file of every revision.
You can do this with svnadmin dump --deltas --incremental -r $REV.
This gives you nearly instant backup of every commit that made it into
the repository. Incremental dump files can be large if a large tree is
added, but in general they don't use much space.

After restoring the last full backup of the repository, load missing
revisions from the incremental dump files generated since the last
full backup was made.

You can either get rid of incremental dump files dated before the
last full backup, or keep them around in case you'll need them some day.
Having multiple backups of your data in different representations
doesn't hurt.

Stefan

Re: Subversion version on server

[Ryan Schmidt]

On Dec 14, 2010, at 09:32, Ludwig, Michael wrote:

>> on command prompt type svn --version  and you will get the required info
> 
> That's for the client.
> 
> The OP asked how to get the version of the server from the clientside.
> (So without access to the serverside.)

Actually, he didn't specify. He asked: "How do I go about finding out what 
version of subversion (e.g. 1.6.#) is on the server." The answer is to go to 
the server and ask it. If you run "svn --version" on the server, it will tell 
you what version of the Subversion client is installed on the server. If you 
run "svnserve --version" on the server, it will tell you what version of 
svnserve is installed on the server.

If your reply is that you don't have access to the server to run these 
commands, then you'll have to talk to someone who does have access to the 
server and have them run those commands for you.

If you want to know what version of mod_dav_svn is installed on the server, 
that can actually be determined from the client, by accessing the repository's 
http or https URL in a web browser. (In fact, I'm not sure how to find out the 
version of mod_dav_svn from the server.)

Re: Subversion version on server

[Ryan Schmidt]

On Dec 14, 2010, at 15:48, r...@elilabs.com wrote:

>> If you want to know what version of mod_dav_svn is installed on the
>> server, that can actually be determined from the client, by accessing the
>> repository's http or https URL in a web browser. (In fact, I'm not sure
>> how to find out the version of mod_dav_svn from the server.)
> 
> If I go to my repository, which is DAV hosted under apache on a linux box,
> using a browser, I see:
> 
> Revision 0
> Collection of Repositories
> IRD/
> conf/
> repos/
> Powered by Subversion 1.6.13 (r1002816)
> 
> in the browser window, so I assume that means the svn server is version
> 1.6.13

Yes, that means the version of mod_dav_svn on the server is 1.6.13.

P.S: Reply All so your reply goes to the list too, not just to me.

Re: Subversion version on server

[Nico Kadel-Garcia]

On Tue, Dec 14, 2010 at 4:58 PM, Ryan Schmidt
 wrote:
> On Dec 14, 2010, at 15:48, r...@elilabs.com wrote:
>
>>> If you want to know what version of mod_dav_svn is installed on the
>>> server, that can actually be determined from the client, by accessing the
>>> repository's http or https URL in a web browser. (In fact, I'm not sure
>>> how to find out the version of mod_dav_svn from the server.)
>>
>> If I go to my repository, which is DAV hosted under apache on a linux box,
>> using a browser, I see:
>>
>> Revision 0
>> Collection of Repositories
>> IRD/
>> conf/
>> repos/
>> Powered by Subversion 1.6.13 (r1002816)
>>
>> in the browser window, so I assume that means the svn server is version
>> 1.6.13
>
> Yes, that means the version of mod_dav_svn on the server is 1.6.13.
>
> P.S: Reply All so your reply goes to the list too, not just to me.

That means that *mod_dav_svn* is 1.6.13. I just encountered a weird
setup where all the work was done in versions randomly selected in
people's .bashrc files, and the webserver was entirely distinct code
and utilities in 1.6.13 (because I built that part separately and
cleanly).