You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com> on 2007/08/17 13:35:44 UTC
Copying (branch/tag), dumping, and filtering repository contents
As most of you know from my prior questions (still hoping for some more
replies), I am dealing with repository load issues. I lack
understanding about how the revision histories work, and the effect upon
dump filters.
What are the best practices in project structure management with respect
to dumps and filters? I read and understand everything about the trunk,
branches, and tags layout, but I am in the dark about dumping, filtering
and loading.
Given the standard layout, if I were to dump the repository and filter
for a specific TAG, what would happen? Would I get a message about
revisions not being found because they're in TRUNK? If not, would I get
all the revisions right back to the initial ADD, which occurred in
trunk? If not, is this considered a problem?
For example, as a DotNet shop, we have several projects that are
referenced together in "solutions". Several of those projects are
effectively "shared" in that they are common libraries, but are
maintained as source code references (rather than DLL references) to
permit ongoing development. The application itself, "/Projects/AAA" has
3 or 4 projects that aren't shared.
Eventually, we decide to start a new branch of the core project, so we
create the branch of AAA (/Projects/AAA/Branches/R2"). We might not
decide to branch the Common ("/Projects/Common") projects.
So:
/Projects/Common
Trunk
------|---- Common1
|---- Common2 ...
Branches
Tags
/Projects/AAA
Trunk
Branches
R2
|----View
|----Business
|----DAL
Tags
The solution contains:
MySln.sln
Common1
Common2
View
Business
DAL
Months go by, and we decide that we want to move R2 and associated
Common projects into a new repository. How would I do that? For that
matter, would we be able to maintain a Visual Studio solution that
referenced two different SVN sources as shown above?
--
David Bicking
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Copying (branch/tag), dumping, and filtering repository
contents
Posted by Les Mikesell <le...@gmail.com>.
Bicking, David (HHoldings, IT) wrote:
>
>
>> I think the reason you didn't get any answers on this one is
>> that the question doesn't make sense. If you have history in
>> trunk, how can you just want to extract one branch and keep
>> history which didn't exist there? Keep in mind that these
>> are 'cheap' copies, not the real thing.
>>
> Les, I truly appreciate that you actually responded, but you are the
> unfortunate recipient of my frustration, it's not personal...
>
> *sigh* The non-answer to my question is "there is no way to do what I
> ask (without hacks), and it is a stupid question in the first place".
> Additionally "nobody would ever want to extract individual projects from
> a repository", and the easily inferred (for the cynical like me), "what
> kind of idiot would put multiple projects in one repository anyway?"
Separating 'projects' isn't an issue at all. The issue is maintaining
history that is not part of the project as you choose to view it
currently. SCM's don't make it easy for you to change history. That's
the reason you use them...
> I asked the questions in an attempt to get a leg up on future planning
> before a disastrous mess could form.
>
> Sorry, but I can tell you that in my 16 years of work as a consultant in
> over eight corporations, these would have been useful for maintenance.
> If you and the others who feel the same way can plan your repository on
> day one so that 8 years down the road, there's absolutely no reason to
> make any modifications, God bless you. You are better planners than
> ANYBODY I've ever seen. Consider running for President/Prime
> Minister/Chancellor.
> And here's my response to your questions above. The scenario I have in
> mind is one in which the company in question DID NOT attempt to plan
> their repository, and now have projects evolving off of each other such
> that there is a huge web of copied/shared/moved files and folders. It
> is impossible to isolate one piece of the puzzle for export, leaving the
> other 10G of garbage behind. They cannot pull out the "Revision 4"
> branch (which is all they care about going forward) because it was
> branched off revision 3, which came from revision 2, etc., and they
> shared a framework project into revision 1, so I can't grab any of the 4
> revisions because ANOTHER project is referenced by revision 1 - which,
> by the way, is corrupt. This kind of repository evolution is what I'm
> trying to eliminate. To do so, I need a good plan. To plan, I need a
> wide range of information and community experience, which is why I came
> here.
The clean way to do this in subversion is to make all parts that can be
shared by other projects external references and to be absolutely sure
that release branches or tags that need to be reproducible in the future
peg the external references to specific revisions. I don't think there
is any easy way to migrate an old cross-linked mess into this design.
The components don't need to be in separate repositories to use
externals to reference them, but it forces the issue if they are.
> Often, in the "Microsoft World(tm)", projects that are separate
> components are frequently designed together. For example, a corporate
> framework and an application that will use it. Eventually, the
> framework reaches a maturity level that makes it able to stand alone and
> be referenced by other projects. Unfortunately, whomever initiated this
> process, put all the code (which is referenced in a single "solution")
> into source control as a single project, say, "project1/" (See my FIRST
> post for a clear example). Now the framework needs to be its own
> "project". So these people, knowing no better, simply copy/share it to
> its own location ("framework1"). Worse, rather than reference compiled
> libraries of this framework, the next three projects directly reference
> the source code, by sharing/copying it into their projects. Let the
> hilarity begin.
>
> Imagine this kind of process over a period of five years, with literally
> dozens of different projects. One day, someone with some organizational
> sense is assigned the task of cleaning up this mess (that would be ME).
> Guess what? It ain't possible, in part because "the question doesn't
> make sense(?)".
Once again, history is what it is, and SCM's just maintain it even if
you wish it were something else.
> Those of us here on this listserv represent a minority community: those
> who care about and are able to plan for source control. Have you all
> only ever experienced "greenfield" SCM projects? Have none of you been
> around in one place long enough to realize one day that your original
> repository design doesn't make sense given the current reality? In my
> experience, reality changes drastically at least every few years.
I'd guess that most places don't migrate the whole history when things
change drastically or have become too much of a mess to fix. Instead
they keep the old SCM around just in case someone really ever wants to
revisit bugs fixed a decade ago and simply export versions at revisions
that anyone would be likely to need and commit those to the new SCM as
a clean starting point - perhaps using the 'vendor drop' approach with
some recent revisions. My own decade+ old repository was in CVS which
converts pretty cleanly and doesn't have cross-linking problems - but
you can't follow the times that someone went into the repository and
renamed, deleted, or moved things.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Copying (branch/tag), dumping, and filtering repository
contents
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2007b@ryandesign.com]
> Sent: Friday, September 07, 2007 5:42 PM
>
> I'll just reply to a few things:
>
> On Sep 7, 2007, at 11:59, Bicking, David (HHoldings, IT) wrote:
>
> > It appears to be impossible in SVN. The most likely scenario for
> > extracting one particular branch, all the way to the root,
> is when one
> > wants or needs to pull out the important information and
> discard the
> > chaff. The most likely situation in which this scenario
> will rear its
> > ugly head is when some poor schmuck like me comes in and
> realizes that
> > the repository was not planned, monitored, or otherwise
> controlled for
> > the previous X years. Secondary to that, is the "mistakes
> were made"
> > scenario, or "well, I didn't expect THAT business process
> change when
> > I set things up 3 years ago!".
>
> What aspect of having a repository not be planned, monitored
> or controlled makes it difficult for you to plan, monitor and
> control it now? You can examine the "svn log" to see what has
> gone on during the time the repository was not monitored. You
> can install post-commit email hooks to inform everybody of
> every commit from now on. If things in the repository are not
> organized the way you like, you can "svn mv" them into the
> correct place now.
... And if in five years I want to grab one or two projects out of the
repository and discard the rest, I cannot.
> It is not usual to archive old revisions. Not in Subversion, anyway.
I noticed that. Fortunately, because it is so efficient, it generally
shouldn't be necessary. I'm speaking of edge cases like the one we're
dealing with in VSS right now.
> Also, it's also not always advantageous to trim away old revisions.
> Sometimes this has the effect of making your repository
> larger on disk, not smaller. Subversion stores revisions as
Duly noted. While I'd not considered that possibility, the goal of my
questions was to pull one branch "down to the root" out of many from
multiple projects, so the situation isn't relevant to my needs.
> deltas against some previous revision, and also, copies are
> cheap in Subversion, meaning that if you have a repository
I understand the cheapness, and love it. I just don't want to be
restricted by it.
> It sounds like you're envisioning repository maintenance
> tasks which are neither necessary nor recommended nor easy.
> My advice is to forget that, and just let your repository grow.
To a point, I totally agree. Again - edge scenarios. I'm dealing with
the situation in VSS where I want to pull out a subset of code with all
its history, and cannot. It's not a devistating situation, but it is
annoying.
> Of course I can't help with your corporate politics. All I
> can do is look at bestbuy.com and see that a 320GB internal
> drive costs about USD 120. Get two of those, make a RAID 1
I understand that, and agree. Thank you for your input, it is very
useful even though my needs aren't met :)
(p.s.; I got a 500GB eSATA for $120 a couple of months ago - absolutely
amazing!)
--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Copying (branch/tag), dumping, and filtering repository contents
Posted by Ryan Schmidt <su...@ryandesign.com>.
I'll just reply to a few things:
On Sep 7, 2007, at 11:59, Bicking, David (HHoldings, IT) wrote:
>> Well, the question that didn't make sense was, "If you have
>> history in trunk, how can you just want to extract one branch
>> and keep history which didn't exist there?" But I'm not sure
>> that's the question you asked.
>>
>> I too have wondered what happens if I have, say, a library in
>> my repository, that originated in a different project, and
>> now I want to move that library to its own repository. It
>> seems that's a difficult task. So I probably won't embark on
>> it; I'll probably keep everything in one repository, because
>> it seems nice to do so anyway.
>
> It appears to be impossible in SVN. The most likely scenario for
> extracting one particular branch, all the way to the root, is when one
> wants or needs to pull out the important information and discard the
> chaff. The most likely situation in which this scenario will rear its
> ugly head is when some poor schmuck like me comes in and realizes that
> the repository was not planned, monitored, or otherwise controlled for
> the previous X years. Secondary to that, is the "mistakes were made"
> scenario, or "well, I didn't expect THAT business process change
> when I
> set things up 3 years ago!".
What aspect of having a repository not be planned, monitored or
controlled makes it difficult for you to plan, monitor and control it
now? You can examine the "svn log" to see what has gone on during the
time the repository was not monitored. You can install post-commit
email hooks to inform everybody of every commit from now on. If
things in the repository are not organized the way you like, you can
"svn mv" them into the correct place now.
One possible problem: if you discover content in the repository that
should not be there, for legal reasons or whatever. So far when
you've talked about wanting to delete old projects I've taken it from
a disk space or neatness/organizational standpoint, about which I'll
say more below. But if things have to be removed for legal reasons,
or you've committed a password file that you shouldn't have, then the
feature you're looking for is the nonexistent "svnadmin obliterate"
which many have requested but which still hasn't really reached the
planning stage; see:
http://subversion.tigris.org/issues/show_bug.cgi?id=516
>> I guess you rather asked how to archive away old projects,
>> especially when a library or another project has been
>> branched off of it at some point. And I think the answer at
>> this point is you don't. You just keep it in the repository.
>
> I can deal with that, if I know that's my only reasonable option. I
> still don't like it. One potential problematic scenario is that one
> might have 10 projects, two of which are currently heavily active.
> There may well be a need and desire to keep all 10 projects in the
> repository, but the two active projects are so active that it becomes
> necessary to archive revisions prior to 6 months ago. Would the
> dump/load process eliminate the other 8 projects because they were
> last
> revised 8 months ago, or would there be a single, full revision of
> them
> left in the repository?
It is not usual to archive old revisions. Not in Subversion, anyway.
Subversion makes it difficult for you to do so: You have to take the
repository offline, dump the part you want to keep (which can take
many hours if your repository is large), make a new repository, load
the dumpfile (more hours), remember to copy back in your hooks and
config files, and bring the repository back online. Everyone who had
a working copy needs to throw it away and check out a new one. If
they had uncommitted work in those working copies, they need to
manually move them over to new working copies. Oh, and any locks you
may have had are now gone.
Also, it's also not always advantageous to trim away old revisions.
Sometimes this has the effect of making your repository larger on
disk, not smaller. Subversion stores revisions as deltas against some
previous revision, and also, copies are cheap in Subversion, meaning
that if you have a repository with just a trunk, and it occupies
100MB, and you create 50 branches off of that, your repository now
occupies maybe 100.000001MB, because all those copied branches are
recorded in the repository as a reference to the trunk. As soon as
you start making changes to the branches, then only those changes
start getting recorded to the repository. It's very space-efficient.
But it can cease to be if you try to trim old revisions. Suppose the
50 braches were created in various revisions up to revision 500, and
that some work has been done on the branches such that your
repository now occupies 200MB for the trunk and all the branches. Now
you decide to trim away the first 600 revisions by dumping revisions
600:HEAD and loading them into a new repository. You can do this, but
now all 50 branches have to be recorded as complete expensive copies,
since the revisions of trunk from which they were initially copied
are now gone. So instead of occupying 200MB, your repository now
occupies, say, 51*100MB = 5.1GB on disk.
It sounds like you're envisioning repository maintenance tasks which
are neither necessary nor recommended nor easy. My advice is to
forget that, and just let your repository grow.
>> If you don't want to see that old project in your main
>> repository list, you can "svn mkdir $REPO_URL/old" and "svn
>> mv $REPO_URL/some_old_project $REPO_URL/old" to get it out of
>> the way, but still accessible. If your complaint is with the
>> disk space occupied by the old projects, then the answer from
>> the Subversion team is probably one of their old standards,
>> namely that disk space is cheap. That's not a great answer
>
> Those of us who work in corporate environments have to battle reality.
> We have a situation now where the VSS repository is 10G, and we can't
> get new disk space allocated. There are processes, procedures,
> governances, etc. Eventually it will happen, but in the mean time
> considerably more money will likely be spent dealing with the problem
> than would have been spent with a quick upgrade. Sometimes, the
> complexity of the environment can make a simple volume increase a
> difficult proposition, I suppose.
>
>> sometimes, but I can see where they're coming from. The cost
>> of an extra hard disk or two is less than the cost of
>> developing svndumpfilter further, or implementing svnadmin
>> obliterate, etc.
>
> It's less financially, not necessarily so in business process reality.
> Thank you for your reply.
Of course I can't help with your corporate politics. All I can do is
look at bestbuy.com and see that a 320GB internal drive costs about
USD 120. Get two of those, make a RAID 1 out of them and stick 'em in
a server with a couple free drive bays, and your repository should be
set for awhile. That's a fixed one-time cost, versus the unknown cost
of however much time and effort it would take you to devise
workarounds to use Subversion in ways it wasn't really designed for
(archiving old revisions to save space, say). Consider possible
downtime too -- how much would it cost your organization if all your
developers are unproductive for an hour because they cannot access
the repository server because it ran out of disk space and had to be
taken down for an upgrade? or because your archiving operation took
longer than anticipated? Better put sufficient disk in it to begin
with, IMHO.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Copying (branch/tag), dumping, and filtering repository
contents
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2007b@ryandesign.com]
> Sent: Thursday, September 06, 2007 2:48 AM
> To: Bicking, David (HHoldings, IT)
> Cc: users@subversion.tigris.org; lesmikesell@gmail.com
> Subject: Re: Copying (branch/tag), dumping, and filtering
> repository contents
>
> Sorry for the trouble, David! I'll try to provide some constructive
> information:
>
>
> On Sep 5, 2007, at 14:12, Bicking, David (HHoldings, IT) wrote:
>
--- snip ---
> > *sigh* The non-answer to my question is "there is no way to
> do what I
> > ask (without hacks), and it is a stupid question in the
> first place".
> > Additionally "nobody would ever want to extract individual projects
> > from
> > a repository", and the easily inferred (for the cynical like me),
> > "what
> > kind of idiot would put multiple projects in one repository anyway?"
>
> I'm such an idiot, for example. :) I think it's very natural
> to have all projects in one repository, especially for the
> reasons you state later on -- that projects evolve and turn
> into other projects or have reusable frameworks branched off
> of them. Much easier to just "svn cp" and "svn mv" to
> rearrange things within a single repository to match whatever
> your current needs are, and the history is preserved, which is nice.
This is precisely what is necessary in a dynamic environment, but you
then lose the ability to extract discrete projects.
>
> I do have two repositories, in fact, but they're for things
> that have nothing to do with one another -- one is for code I
> write, the other is for music I compose.
>
> Some people like putting each project into its own
> repository. To each his own. There are pros and cons to each approach.
Exactly! I want to know the best practices of each approach.
--- snip ---
> > I need a wide range of information and community
> experience, which is
> > why I came here.
>
> Well, you shouldn't have any revisions that are corrupt. I
> know we hear about that all the time on the list, but you
> should have a good backup strategy which involves making a
> copy of the revision the instant it's created, in a
> post-commit hook. Then back up those copies often, to CD or
> DVD or tape or what have you, so that you permanently save a
> good copy of the revision, so that if it ever gets corrupted
> because your main disks go bad, restoring it is a quick and
> painless non-issue.
I totally agree. In this case, it is a VSS repository, so it comes with
the territory.
--- snip ---
> I don't have experience with compiled-library development; I
> only make PHP web sites and shell scripts and such, so that
> the only way to share the functionality is to share the
> source code. But that's
> fine: with svn:externals you can pull in code from other
> places in the repository, or from other repositories.
I examined svn:externals, and think it might be useful, but it has
caveats and I'm unsure if it has any side effects.
--- snip ---
>
> Well, the question that didn't make sense was, "If you have
> history in trunk, how can you just want to extract one branch
> and keep history which didn't exist there?" But I'm not sure
> that's the question you asked.
>
> I too have wondered what happens if I have, say, a library in
> my repository, that originated in a different project, and
> now I want to move that library to its own repository. It
> seems that's a difficult task. So I probably won't embark on
> it; I'll probably keep everything in one repository, because
> it seems nice to do so anyway.
It appears to be impossible in SVN. The most likely scenario for
extracting one particular branch, all the way to the root, is when one
wants or needs to pull out the important information and discard the
chaff. The most likely situation in which this scenario will rear its
ugly head is when some poor schmuck like me comes in and realizes that
the repository was not planned, monitored, or otherwise controlled for
the previous X years. Secondary to that, is the "mistakes were made"
scenario, or "well, I didn't expect THAT business process change when I
set things up 3 years ago!".
>
> I guess you rather asked how to archive away old projects,
> especially when a library or another project has been
> branched off of it at some point. And I think the answer at
> this point is you don't. You just keep it in the repository.
I can deal with that, if I know that's my only reasonable option. I
still don't like it. One potential problematic scenario is that one
might have 10 projects, two of which are currently heavily active.
There may well be a need and desire to keep all 10 projects in the
repository, but the two active projects are so active that it becomes
necessary to archive revisions prior to 6 months ago. Would the
dump/load process eliminate the other 8 projects because they were last
revised 8 months ago, or would there be a single, full revision of them
left in the repository?
> If you don't want to see that old project in your main
> repository list, you can "svn mkdir $REPO_URL/old" and "svn
> mv $REPO_URL/some_old_project $REPO_URL/old" to get it out of
> the way, but still accessible. If your complaint is with the
> disk space occupied by the old projects, then the answer from
> the Subversion team is probably one of their old standards,
> namely that disk space is cheap. That's not a great answer
Those of us who work in corporate environments have to battle reality.
We have a situation now where the VSS repository is 10G, and we can't
get new disk space allocated. There are processes, procedures,
governances, etc. Eventually it will happen, but in the mean time
considerably more money will likely be spent dealing with the problem
than would have been spent with a quick upgrade. Sometimes, the
complexity of the environment can make a simple volume increase a
difficult proposition, I suppose.
> sometimes, but I can see where they're coming from. The cost
> of an extra hard disk or two is less than the cost of
> developing svndumpfilter further, or implementing svnadmin
> obliterate, etc.
It's less financially, not necessarily so in business process reality.
Thank you for your reply.
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Copying (branch/tag), dumping, and filtering repository contents
Posted by Ryan Schmidt <su...@ryandesign.com>.
Sorry for the trouble, David! I'll try to provide some constructive
information:
On Sep 5, 2007, at 14:12, Bicking, David (HHoldings, IT) wrote:
>>> That's why I am perplexed at the inability to extract specific
>>> paths (described at the tip) and get all the information back
>>> to the earliest revision, even if it was not in the tip path at
>>> the time it was created.
>>
>> I think the reason you didn't get any answers on this one is
>> that the question doesn't make sense. If you have history in
>> trunk, how can you just want to extract one branch and keep
>> history which didn't exist there? Keep in mind that these
>> are 'cheap' copies, not the real thing.
>
> *sigh* The non-answer to my question is "there is no way to do what I
> ask (without hacks), and it is a stupid question in the first place".
> Additionally "nobody would ever want to extract individual projects
> from
> a repository", and the easily inferred (for the cynical like me),
> "what
> kind of idiot would put multiple projects in one repository anyway?"
I'm such an idiot, for example. :) I think it's very natural to have
all projects in one repository, especially for the reasons you state
later on -- that projects evolve and turn into other projects or have
reusable frameworks branched off of them. Much easier to just "svn
cp" and "svn mv" to rearrange things within a single repository to
match whatever your current needs are, and the history is preserved,
which is nice.
I do have two repositories, in fact, but they're for things that have
nothing to do with one another -- one is for code I write, the other
is for music I compose.
Some people like putting each project into its own repository. To
each his own. There are pros and cons to each approach.
> I asked the questions in an attempt to get a leg up on future planning
> before a disastrous mess could form.
>
> Sorry, but I can tell you that in my 16 years of work as a
> consultant in
> over eight corporations, these would have been useful for maintenance.
> If you and the others who feel the same way can plan your
> repository on
> day one so that 8 years down the road, there's absolutely no reason to
> make any modifications, God bless you. You are better planners than
> ANYBODY I've ever seen. Consider running for President/Prime
> Minister/Chancellor.
>
> And here's my response to your questions above. The scenario I
> have in
> mind is one in which the company in question DID NOT attempt to plan
> their repository, and now have projects evolving off of each other
> such
> that there is a huge web of copied/shared/moved files and folders. It
> is impossible to isolate one piece of the puzzle for export,
> leaving the
> other 10G of garbage behind. They cannot pull out the "Revision 4"
> branch (which is all they care about going forward) because it was
> branched off revision 3, which came from revision 2, etc., and they
> shared a framework project into revision 1, so I can't grab any of
> the 4
> revisions because ANOTHER project is referenced by revision 1 - which,
> by the way, is corrupt. This kind of repository evolution is what I'm
> trying to eliminate. To do so, I need a good plan. To plan, I need a
> wide range of information and community experience, which is why I
> came
> here.
Well, you shouldn't have any revisions that are corrupt. I know we
hear about that all the time on the list, but you should have a good
backup strategy which involves making a copy of the revision the
instant it's created, in a post-commit hook. Then back up those
copies often, to CD or DVD or tape or what have you, so that you
permanently save a good copy of the revision, so that if it ever gets
corrupted because your main disks go bad, restoring it is a quick and
painless non-issue.
> Often, in the "Microsoft World(tm)", projects that are separate
> components are frequently designed together. For example, a corporate
> framework and an application that will use it. Eventually, the
> framework reaches a maturity level that makes it able to stand
> alone and
> be referenced by other projects. Unfortunately, whomever initiated
> this
> process, put all the code (which is referenced in a single "solution")
> into source control as a single project, say, "project1/" (See my
> FIRST
> post for a clear example). Now the framework needs to be its own
> "project". So these people, knowing no better, simply copy/share
> it to
> its own location ("framework1"). Worse, rather than reference
> compiled
> libraries of this framework, the next three projects directly
> reference
> the source code, by sharing/copying it into their projects. Let the
> hilarity begin.
I don't have experience with compiled-library development; I only
make PHP web sites and shell scripts and such, so that the only way
to share the functionality is to share the source code. But that's
fine: with svn:externals you can pull in code from other places in
the repository, or from other repositories.
> Imagine this kind of process over a period of five years, with
> literally
> dozens of different projects. One day, someone with some
> organizational
> sense is assigned the task of cleaning up this mess (that would be
> ME).
> Guess what? It ain't possible, in part because "the question doesn't
> make sense(?)".
Well, the question that didn't make sense was, "If you have history
in trunk, how can you just want to extract one branch and keep
history which didn't exist there?" But I'm not sure that's the
question you asked.
I too have wondered what happens if I have, say, a library in my
repository, that originated in a different project, and now I want to
move that library to its own repository. It seems that's a difficult
task. So I probably won't embark on it; I'll probably keep everything
in one repository, because it seems nice to do so anyway.
I guess you rather asked how to archive away old projects, especially
when a library or another project has been branched off of it at some
point. And I think the answer at this point is you don't. You just
keep it in the repository. If you don't want to see that old project
in your main repository list, you can "svn mkdir $REPO_URL/old" and
"svn mv $REPO_URL/some_old_project $REPO_URL/old" to get it out of
the way, but still accessible. If your complaint is with the disk
space occupied by the old projects, then the answer from the
Subversion team is probably one of their old standards, namely that
disk space is cheap. That's not a great answer sometimes, but I can
see where they're coming from. The cost of an extra hard disk or two
is less than the cost of developing svndumpfilter further, or
implementing svnadmin obliterate, etc.
> Those of us here on this listserv represent a minority community:
> those
> who care about and are able to plan for source control. Have you all
> only ever experienced "greenfield" SCM projects? Have none of you
> been
> around in one place long enough to realize one day that your original
> repository design doesn't make sense given the current reality? In my
> experience, reality changes drastically at least every few years.
>
> I'm not expecting constructive replies to this, I'm clearly on my
> own on
> this particular topic, and I'll deal with that. I'm just wholly
> surprised these issues are neither common, nor addressed. I've never
> seen a "clean" SCM repository that I didn't build myself.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Copying (branch/tag), dumping, and filtering repository
contents
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Wednesday, September 05, 2007 11:32 AM
> To: Bicking, David (HHoldings, IT)
> Cc: users@subversion.tigris.org
> Subject: Re: Copying (branch/tag), dumping, and filtering
> repository contents
>
> > No. I am evaluating various SCM packages and don't have
> the resources
> > to experiment that way, even if I did have a repository on which to
> > experiment.
>
> You don't have a computer with some disk space? Subversion
> will create a repository in your local file system that works
> just the same as server-based repositories.
As I said originally, I don't have the time or resources to make it up
and play around to figure this out. I already spent a week failing to
migrate a 10G VSS repository for tests. That time was way out of scope
for this project effort.
> > Is it unusual for people to divide large repositories into
> smaller ones?
>
> If you are worried about this, you could put each project in
> its own repository to start with and use http access which
> can make all of the URLs look the same as a single repository.
This company will not use Apache if they choose SVN, though the idea
intrests me. I'll research it.
> > That's why I am perplexed at the inability to extract
> specific paths
> > (described at the tip) and get all the information back to the
> > earliest revision, even if it was not in the tip path at
> the time it was created.
> I think the reason you didn't get any answers on this one is
> that the question doesn't make sense. If you have history in
> trunk, how can you just want to extract one branch and keep
> history which didn't exist there? Keep in mind that these
> are 'cheap' copies, not the real thing.
>
Les, I truly appreciate that you actually responded, but you are the
unfortunate recipient of my frustration, it's not personal...
*sigh* The non-answer to my question is "there is no way to do what I
ask (without hacks), and it is a stupid question in the first place".
Additionally "nobody would ever want to extract individual projects from
a repository", and the easily inferred (for the cynical like me), "what
kind of idiot would put multiple projects in one repository anyway?"
I asked the questions in an attempt to get a leg up on future planning
before a disastrous mess could form.
Sorry, but I can tell you that in my 16 years of work as a consultant in
over eight corporations, these would have been useful for maintenance.
If you and the others who feel the same way can plan your repository on
day one so that 8 years down the road, there's absolutely no reason to
make any modifications, God bless you. You are better planners than
ANYBODY I've ever seen. Consider running for President/Prime
Minister/Chancellor.
And here's my response to your questions above. The scenario I have in
mind is one in which the company in question DID NOT attempt to plan
their repository, and now have projects evolving off of each other such
that there is a huge web of copied/shared/moved files and folders. It
is impossible to isolate one piece of the puzzle for export, leaving the
other 10G of garbage behind. They cannot pull out the "Revision 4"
branch (which is all they care about going forward) because it was
branched off revision 3, which came from revision 2, etc., and they
shared a framework project into revision 1, so I can't grab any of the 4
revisions because ANOTHER project is referenced by revision 1 - which,
by the way, is corrupt. This kind of repository evolution is what I'm
trying to eliminate. To do so, I need a good plan. To plan, I need a
wide range of information and community experience, which is why I came
here.
Often, in the "Microsoft World(tm)", projects that are separate
components are frequently designed together. For example, a corporate
framework and an application that will use it. Eventually, the
framework reaches a maturity level that makes it able to stand alone and
be referenced by other projects. Unfortunately, whomever initiated this
process, put all the code (which is referenced in a single "solution")
into source control as a single project, say, "project1/" (See my FIRST
post for a clear example). Now the framework needs to be its own
"project". So these people, knowing no better, simply copy/share it to
its own location ("framework1"). Worse, rather than reference compiled
libraries of this framework, the next three projects directly reference
the source code, by sharing/copying it into their projects. Let the
hilarity begin.
Imagine this kind of process over a period of five years, with literally
dozens of different projects. One day, someone with some organizational
sense is assigned the task of cleaning up this mess (that would be ME).
Guess what? It ain't possible, in part because "the question doesn't
make sense(?)".
Those of us here on this listserv represent a minority community: those
who care about and are able to plan for source control. Have you all
only ever experienced "greenfield" SCM projects? Have none of you been
around in one place long enough to realize one day that your original
repository design doesn't make sense given the current reality? In my
experience, reality changes drastically at least every few years.
I'm not expecting constructive replies to this, I'm clearly on my own on
this particular topic, and I'll deal with that. I'm just wholly
surprised these issues are neither common, nor addressed. I've never
seen a "clean" SCM repository that I didn't build myself.
--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Copying (branch/tag), dumping, and filtering repository contents
Posted by Les Mikesell <le...@gmail.com>.
Bicking, David (HHoldings, IT) wrote:
>
>>> Alright, one more time, and then I give up. I though this
>> would be a
>>> relatively simple question, but apparently I was wrong.
>> Have you experimented for yourself (using a backup copy of
>> your repository, of course) to see what happens?
>
> No. I am evaluating various SCM packages and don't have the resources
> to experiment that way, even if I did have a repository on which to
> experiment.
You don't have a computer with some disk space? Subversion will create
a repository in your local file system that works just the same as
server-based repositories.
> Even if I had more resources, it wouldn't help me determine
> a "best practice". It would be days or weeks of wasted effort. I
> figured out from my problems with failing to migrate VSS to SVN that
> svndumpfilter does not follow outside the specified path(s) to get
> earlier copied-in revisions. There is no request other than my own to
> implement such a feature. I expected this to be a problem for others
> besides myself when seeking to divide repositories or keep a piece while
> discarding others. It appears I'm thinking about this differently than
> most.
Yes, usually you'd keep project/trunk project/branches project/tags and
keep them all together at the project level even if you put multiple
projects in one repository and later split them out.
> Is it unusual for people to divide large repositories into smaller ones?
> Does nobody extract and archive projects no longer in active
> development? In fact, I can't find any reference to "archive" practices
> at all in the documentation. I guess the "dump all, load from recent
> revision" method is the way to go with that. Still, that is blind to
> different logical projects (folders), and some projects could be
> archived out when that isn't desired.
If you are worried about this, you could put each project in its own
repository to start with and use http access which can make all of the
URLs look the same as a single repository.
> That's why I am perplexed at the inability to extract specific paths
> (described at the tip) and get all the information back to the earliest
> revision, even if it was not in the tip path at the time it was created.
> Since that's not possible, I am looking for a repository design that
> would enable this capability. From what I can see now, with the common
> practice, I have to grab everything from "/project1" even if I just want
> to extract "/project1/branches/releaseXYZ" because it depends upon (at
> the very least) "trunk".
I think the reason you didn't get any answers on this one is that the
question doesn't make sense. If you have history in trunk, how can you
just want to extract one branch and keep history which didn't exist
there? Keep in mind that these are 'cheap' copies, not the real thing.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Copying (branch/tag), dumping, and filtering repository
contents
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
> Sent: Wednesday, September 05, 2007 8:27 AM
> To: Bicking, David (HHoldings, IT)
> Cc: users@subversion.tigris.org
> Subject: Re: Copying (branch/tag), dumping, and filtering
> repository contents
>
> On 9/5/07, Bicking, David (HHoldings, IT)
> <Da...@thehartford.com> wrote:
> > Alright, one more time, and then I give up. I though this
> would be a
> > relatively simple question, but apparently I was wrong.
>
> Have you experimented for yourself (using a backup copy of
> your repository, of course) to see what happens?
No. I am evaluating various SCM packages and don't have the resources
to experiment that way, even if I did have a repository on which to
experiment. Even if I had more resources, it wouldn't help me determine
a "best practice". It would be days or weeks of wasted effort. I
figured out from my problems with failing to migrate VSS to SVN that
svndumpfilter does not follow outside the specified path(s) to get
earlier copied-in revisions. There is no request other than my own to
implement such a feature. I expected this to be a problem for others
besides myself when seeking to divide repositories or keep a piece while
discarding others. It appears I'm thinking about this differently than
most.
Is it unusual for people to divide large repositories into smaller ones?
Does nobody extract and archive projects no longer in active
development? In fact, I can't find any reference to "archive" practices
at all in the documentation. I guess the "dump all, load from recent
revision" method is the way to go with that. Still, that is blind to
different logical projects (folders), and some projects could be
archived out when that isn't desired.
That's why I am perplexed at the inability to extract specific paths
(described at the tip) and get all the information back to the earliest
revision, even if it was not in the tip path at the time it was created.
Since that's not possible, I am looking for a repository design that
would enable this capability. From what I can see now, with the common
practice, I have to grab everything from "/project1" even if I just want
to extract "/project1/branches/releaseXYZ" because it depends upon (at
the very least) "trunk".
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Copying (branch/tag), dumping, and filtering repository contents
Posted by Andy Levy <an...@gmail.com>.
On 9/5/07, Bicking, David (HHoldings, IT) <Da...@thehartford.com> wrote:
> Alright, one more time, and then I give up. I though this would be a
> relatively simple question, but apparently I was wrong.
Have you experimented for yourself (using a backup copy of your
repository, of course) to see what happens?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Copying (branch/tag), dumping, and filtering repository
contents
Posted by Neil Martinsen-Burrell <nm...@wartburg.edu>.
On Fri, Sep 14, 2007 at 08:59:18AM -0400, Bicking, David (HHoldings, IT) wrote:
> Thank you very much for this sumary of the three versions of the
> svndumpfilter alternatives. If I read this correctly, these programs
> essentially truncate history at the point of "copy-in". Would it be
> particularly problematic if such a program instead kept track of those
> copied-in items, and changed the path of the prior versions to match the
> most recent copy? I proposed this earlier
> (http://svn.haxx.se/users/archive-2007-08/0435.shtml). I haven't
> examined the dumpfile format in detail, but I think it can be done. I
> have it on my list of ideas for when I have time to do some OSS
> development. It seems to me to be a potentially valuable feature for
> larger organizations that would like to keep a few choice pieces of very
> large repositories at the cost of potential duplication of some
> historical files.
You are correct. All of the above cut off history at the point of
copy-in. I do believe that it might be possible to modify those tools
to keep some history before the copy-in. Possible problems in the
include:
1. You have to add the entire directory structure containing the file
that was copied-in. The added item must live in some node in the tree
so you have to include the directory that it lives in. This is true all
the way up the file hierarchy. You could rewrite the location of the
copied-from file, but you have to do that consistently throughout the
previous history. Of course, this is true for and copy-ins that take
place in the history of the fopied-from file.
2. You will be changing the contents of individual commits (not a big
deal, since you always run that risk) by leaving out, say, the other
files added in a commit that added your copied-from file.
3. You need to go through the dumpfile backwards, unlike the filters
mentioned above, and keep track of all the things that you are tracking
back in time in addition to the things you are keeping because of your
filter.
> Of course, some heuristics could be used to determine the case where
> multiple streamlined paths reference the same history that is outside
> the filter, streamline it into one, and "copy" that into the others.
> This would reduce the incidence of "duplicate history". For
> particularly large repositories where one wants to grab say six or seven
> paths, a "path list file" could be referenced as a parameter to specify
> the paths desired. I think this would give one exactly the desired
> projects, with minimal bloat, while automagically reorganizing the
> versions into desired paths. Essentially, this is a repository
> reorganization and compaction.
Someone who wished to scratch this itch certainly could do it. I am not
a commercial software developer, so I may have a different feeling about
the importance of history, but for me the history of the file before it
was copied into my path is not of great value. If that history is of
*significant* value, then it would be worth it to create a tool that
could do this. Peace,
-Neil
--
Neil Martinsen-Burrell
nmb@wartburg.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Copying (branch/tag), dumping, and filtering repository contents
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Neil
> Martinsen-Burrell
> Bicking, David (HHoldings, IT <David.Bicking <at>
> thehartford.com> writes:
>
> > Alright, one more time, and then I give up. I though this
> would be a
> > relatively simple question, but apparently I was wrong.
>
> It is possible to filter out deeply-nested subdirectories
> from SVN repositories.
----- <snip> ----
>
> One might desire a solution that would keep the history of
> the file that was copied from an excluded path, but then it
> would also have to keep the history of any ancestors of the
> original, excluded file and so forth. This would result in a
> filtered repository that could potentially include a great
> deal of stuff other than the filtered paths. The above
> solution avoids that problem.
>
Thank you very much for this sumary of the three versions of the
svndumpfilter alternatives. If I read this correctly, these programs
essentially truncate history at the point of "copy-in". Would it be
particularly problematic if such a program instead kept track of those
copied-in items, and changed the path of the prior versions to match the
most recent copy? I proposed this earlier
(http://svn.haxx.se/users/archive-2007-08/0435.shtml). I haven't
examined the dumpfile format in detail, but I think it can be done. I
have it on my list of ideas for when I have time to do some OSS
development. It seems to me to be a potentially valuable feature for
larger organizations that would like to keep a few choice pieces of very
large repositories at the cost of potential duplication of some
historical files.
Of course, some heuristics could be used to determine the case where
multiple streamlined paths reference the same history that is outside
the filter, streamline it into one, and "copy" that into the others.
This would reduce the incidence of "duplicate history". For
particularly large repositories where one wants to grab say six or seven
paths, a "path list file" could be referenced as a parameter to specify
the paths desired. I think this would give one exactly the desired
projects, with minimal bloat, while automagically reorganizing the
versions into desired paths. Essentially, this is a repository
reorganization and compaction.
--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Copying (branch/tag), dumping, and filtering repository contents
Posted by Neil Martinsen-Burrell <nm...@wartburg.edu>.
Bicking, David (HHoldings, IT <David.Bicking <at> thehartford.com> writes:
> Alright, one more time, and then I give up. I though this would be a
> relatively simple question, but apparently I was wrong.
It is possible to filter out deeply-nested subdirectories from SVN repositories.
It is not possible to do so using svndumpfilter however. It will fail (as you
may have noticed) on a revision that copies a file from an excluded path to an
included one. A (consistent if not ideal) solution is to mark such a copy as an
add of new content in the filtered repository. This is the approach taken by
Simon Tatham's svndumpfilter2
(www.tartarus.org/~simon-anonsvn/viewcvs.cgi/svn-tools/svndumpfilter2), Martin
Blais's svndumpfilter3
(http://furius.ca/pubcode/pub/conf/common/bin/svndumpfilter3.html) and my own
svndumpfilter4.py (https://www.undersea.com/~nburrell/svndumpfilter4). Simon's
is the root of all three of these possibilities, but they are all slightly
different in what they allow for exclusions and inclusions.
One might desire a solution that would keep the history of the file that was
copied from an excluded path, but then it would also have to keep the history of
any ancestors of the original, excluded file and so forth. This would result in
a filtered repository that could potentially include a great deal of stuff other
than the filtered paths. The above solution avoids that problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: RCS 2 SVN Conversion
Posted by Michael Haggerty <mh...@alum.mit.edu>.
Troy Curtis Jr wrote:
> On 9/6/07, Erik Huelsmann <eh...@gmail.com> wrote:
>> On 9/6/07, Dong Jiwei <do...@keithley.com> wrote:
>>> Hi all,
>>>
>>> Currently my team are using RCS to manage all the script files. We
>>> want to change the Revision management system to SVN, but the repository is
>>> very big, the file directory are a little deep.
>>> Is there any good tool that can automatically convert the RCS
>>> repository to SVN?
>>>
>>> I have checked the rcs2svn.pl, but I am not good at perl, there is
>>> error message that I can not solve.
>> Try cvs2svn and organizing your files in such a way that cvs2svn can
>> process them.
>
> To further expand on Erik's instructions. CVS basically uses RCS and
> as such RCS->CVS is extremely easy. Simply take all the RCS file
> under the RCS directory in your working copy, move them up a directory
> and then delete the now empty RCS directory. Remeber to always make a
> backup before doing these kinds of things. Now, you have a cvs
> repository (or as much of one as cvs2svn.pl needs).
The only other thing that cvs2svn needs is a "CVSROOT" directory within
the top level of the repository. The directory can be empty.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: RCS 2 SVN Conversion
Posted by Troy Curtis Jr <tr...@gmail.com>.
On 9/6/07, Erik Huelsmann <eh...@gmail.com> wrote:
> On 9/6/07, Dong Jiwei <do...@keithley.com> wrote:
> > Hi all,
> >
> > Currently my team are using RCS to manage all the script files. We
> > want to change the Revision management system to SVN, but the repository is
> > very big, the file directory are a little deep.
> > Is there any good tool that can automatically convert the RCS
> > repository to SVN?
> >
> > I have checked the rcs2svn.pl, but I am not good at perl, there is
> > error message that I can not solve.
>
> Try cvs2svn and organizing your files in such a way that cvs2svn can
> process them.
>
> bye,
>
> Erik.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
To further expand on Erik's instructions. CVS basically uses RCS and
as such RCS->CVS is extremely easy. Simply take all the RCS file
under the RCS directory in your working copy, move them up a directory
and then delete the now empty RCS directory. Remeber to always make a
backup before doing these kinds of things. Now, you have a cvs
repository (or as much of one as cvs2svn.pl needs).
With a large repo, cvs2svn.pl might take a while, but it does do
things very intelligently. In my case, revisions of different files
were able to be rolled up into one Subversion revision to make a
for-real "change-set". cvs2svn.pl keyed on the fact that the log
messages were EXACTLY the same and they happened around the same time.
Also, I suggest trying both FSFS and BDB as backends to your new
Subversion repo (if your cvs2svn conversion takes as long as mine did,
this will be pretty time consuming). I found that with our working
copy (>300MB, lots of files, lots of directories and lots of depth)
FSFS performance on checkout and switch operations was unacceptably
long. Things generally seemed faster using the BDB. You may (or may
not) run into the same thing.
Hope it helps.
Troy
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: RCS 2 SVN Conversion
Posted by Erik Huelsmann <eh...@gmail.com>.
On 9/6/07, Dong Jiwei <do...@keithley.com> wrote:
> Hi all,
>
> Currently my team are using RCS to manage all the script files. We
> want to change the Revision management system to SVN, but the repository is
> very big, the file directory are a little deep.
> Is there any good tool that can automatically convert the RCS
> repository to SVN?
>
> I have checked the rcs2svn.pl, but I am not good at perl, there is
> error message that I can not solve.
Try cvs2svn and organizing your files in such a way that cvs2svn can
process them.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RCS 2 SVN Conversion
Posted by Dong Jiwei <do...@keithley.com>.
Hi all,
Currently my team are using RCS to manage all the script files. We
want to change the Revision management system to SVN, but the repository is
very big, the file directory are a little deep.
Is there any good tool that can automatically convert the RCS
repository to SVN?
I have checked the rcs2svn.pl, but I am not good at perl, there is
error message that I can not solve.
Regards,
Roy Dong
_____________________________________________________________________________
Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
AW: Problem with renaming a branch
Posted by "von Bargen, Joergen" <Jo...@SARTORIUS.com>.
Yeah, thanks a lot
It worked ;-)
-----Ursprüngliche Nachricht-----
Von: Ryan Schmidt [mailto:subversion-2007b@ryandesign.com]
Gesendet: Donnerstag, 6. September 2007 05:55
An: von Bargen, Joergen
Cc: users@subversion.tigris.org
Betreff: Re: Problem with renaming a branch
On Sep 5, 2007, at 07:36, von Bargen, Joergen wrote:
> In a very large project I've tried to rename a lot of stuff via
> scripting and at a specific point I always get an error.
>
> I could reduce the problem to a single commmand and get it
> reproduceable.
>
> Use the attached makefile _in_an_empty_folder_ and you'll get the
> error.
[snip]
I've not tried your script. But:
> svn co --non-recursive $(REPOS_PATH) $(TMP_PATH)
> svn co --non-recursive $(REPOS_PATH)/proj $(TMP_PATH)/
> proj
> svn co --non-recursive $(REPOS_PATH)/proj/branches $(TMP_PATH)/
> proj/branches
> svn co --ignore-externals $(REPOS_PATH)/proj/trunk $(TMP_PATH)/
> proj/trunk
That's not how to do what you want to do. Instead, you should:
svn co --non-recursive $(REPOS_PATH) $(TMP_PATH)
svn up --non-recursive $(TMP_PATH)/proj
svn up --non-recursive $(TMP_PATH)/proj/branches
svn up --ignore-externals $(TMP_PATH)/proj/trunk
Maybe that will help you.
-----------------------------------------------------------------------------
This message has been checked for all known viruses and filtered for SPAM contents by the new central scan services at Sartorius!
Disclaimer :
The information contained in this e-mail is intended only for the individual
addressed. If you have received this e-mail by mistake, please notify us
immediately by return reply. Be sure to delete this message and all its
attachments from your system. Please note that any unauthorized review,
copying, disclosure or any other use of this information is strictly
prohibited. E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost, destroyed,
received late or incomplete, or could contain viruses. The sender therefore
does not accept any liability for any error or omission in the content of
this message, either of which are caused as a result of e-mail transmission.
If verification is required, please request a hard-copy version.
Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problem with renaming a branch
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 5, 2007, at 07:36, von Bargen, Joergen wrote:
> In a very large project I've tried to rename a lot of stuff via
> scripting and at a specific point I always get an error.
>
> I could reduce the problem to a single commmand and get it
> reproduceable.
>
> Use the attached makefile _in_an_empty_folder_ and you'll get the
> error.
[snip]
I've not tried your script. But:
> svn co --non-recursive $(REPOS_PATH) $(TMP_PATH)
> svn co --non-recursive $(REPOS_PATH)/proj $(TMP_PATH)/
> proj
> svn co --non-recursive $(REPOS_PATH)/proj/branches $(TMP_PATH)/
> proj/branches
> svn co --ignore-externals $(REPOS_PATH)/proj/trunk $(TMP_PATH)/
> proj/trunk
That's not how to do what you want to do. Instead, you should:
svn co --non-recursive $(REPOS_PATH) $(TMP_PATH)
svn up --non-recursive $(TMP_PATH)/proj
svn up --non-recursive $(TMP_PATH)/proj/branches
svn up --ignore-externals $(TMP_PATH)/proj/trunk
Maybe that will help you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Problem with renaming a branch
Posted by "von Bargen, Joergen" <Jo...@SARTORIUS.COM>.
Hi Folks,
In a very large project I've tried to rename a lot of stuff via scripting and at a specific point I always get an error.
I could reduce the problem to a single commmand and get it reproduceable.
Use the attached makefile _in_an_empty_folder_ and you'll get the error.
The makefile will
* create an initial blank new repository
* create a project with some files
* copy the trunk to a branch
* copy the branch to another branch
* rename a branch (this is where the error occurs)
Does anyone have a suggestion how to fix this or
a workaround?
I've already tried to replace the mv with as cp & rm, but the rm failes the same way.
TIA for any help
jørgen
Disclaimer :
The information contained in this e-mail is intended only for the individual
addressed. If you have received this e-mail by mistake, please notify us
immediately by return reply. Be sure to delete this message and all its
attachments from your system. Please note that any unauthorized review,
copying, disclosure or any other use of this information is strictly
prohibited. E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost, destroyed,
received late or incomplete, or could contain viruses. The sender therefore
does not accept any liability for any error or omission in the content of
this message, either of which are caused as a result of e-mail transmission.
If verification is required, please request a hard-copy version.
Thank you.
RE: Copying (branch/tag), dumping, and filtering repository contents
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
Alright, one more time, and then I give up. I though this would be a
relatively simple question, but apparently I was wrong.
> -----Original Message-----
> From: Bicking, David (HHoldings, IT)
> Sent: Friday, August 24, 2007 9:08 AM
> To: Bicking, David (HHoldings, IT); users@subversion.tigris.org
> Subject: RE: Copying (branch/tag), dumping, and filtering
> repository contents
>
> I'm reposting a question below, as nobody answered yet.
>
> > As most of you know from my prior questions (still hoping for some
> > more replies), I am dealing with repository load issues.
> > I lack understanding about how the revision histories
> work, and the
> > effect upon dump filters.
> >
> > What are the best practices in project structure management with
> > respect to dumps and filters? I read and understand
> everything about
> > the trunk, branches, and tags layout, but I am in the dark about
> > dumping, filtering and loading.
> >
> > Given the standard layout, if I were to dump the repository
> and filter
> > for a specific TAG, what would happen? Would I get a message about
> > revisions not being found because they're in TRUNK? If
> not, would I
> > get all the revisions right back to the initial ADD, which
> occurred in
> > trunk? If not, is this considered a problem?
> >
> > For example, as a DotNet shop, we have several projects that are
> > referenced together in "solutions". Several of those projects are
> > effectively "shared" in that they are common libraries, but are
> > maintained as source code references (rather than DLL
> references) to
> > permit ongoing development.
> > The application itself, "/Projects/AAA" has
> > 3 or 4 projects that aren't shared.
> >
> > Eventually, we decide to start a new branch of the core
> project, so we
> > create the branch of AAA (/Projects/AAA/Branches/R2"). We
> might not
> > decide to branch the Common ("/Projects/Common") projects.
> >
> > So:
> > /Projects/Common
> > Trunk
> > ------|---- Common1
> > |---- Common2 ...
> > Branches
> > Tags
> >
> > /Projects/AAA
> > Trunk
> > Branches
> > R2
> > |----View
> > |----Business
> > |----DAL
> > Tags
> >
> > The solution contains:
> > MySln.sln
> > Common1
> > Common2
> > View
> > Business
> > DAL
> >
> > Months go by, and we decide that we want to move R2 and associated
> > Common projects into a new repository. How would I do
> that? For that
> > matter, would we be able to maintain a Visual Studio solution that
> > referenced two different SVN sources as shown above?
> >
> >
> > --
> > David Bicking
> >
> >
> > **************************************************************
> > ***********
> > This communication, including attachments, is for the
> exclusive use of
> > addressee and may contain proprietary, confidential and/or
> privileged
> > information. If you are not the intended recipient, any
> use, copying,
> > disclosure, dissemination or distribution is strictly
> prohibited. If
> > you are not the intended recipient, please notify the sender
> > immediately by return e-mail, delete this communication and destroy
> > all copies.
> > **************************************************************
> > ***********
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Copying (branch/tag), dumping, and filtering repository contents
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
I'm reposting a question below, as nobody answered yet.
> As most of you know from my prior questions (still hoping for
> some more replies), I am dealing with repository load issues.
> I lack understanding about how the revision histories work,
> and the effect upon dump filters.
>
> What are the best practices in project structure management
> with respect to dumps and filters? I read and understand
> everything about the trunk, branches, and tags layout, but I
> am in the dark about dumping, filtering and loading.
>
> Given the standard layout, if I were to dump the repository
> and filter for a specific TAG, what would happen? Would I
> get a message about revisions not being found because they're
> in TRUNK? If not, would I get all the revisions right back
> to the initial ADD, which occurred in trunk? If not, is this
> considered a problem?
>
> For example, as a DotNet shop, we have several projects that
> are referenced together in "solutions". Several of those
> projects are effectively "shared" in that they are common
> libraries, but are maintained as source code references
> (rather than DLL references) to permit ongoing development.
> The application itself, "/Projects/AAA" has
> 3 or 4 projects that aren't shared.
>
> Eventually, we decide to start a new branch of the core
> project, so we create the branch of AAA
> (/Projects/AAA/Branches/R2"). We might not decide to branch
> the Common ("/Projects/Common") projects.
>
> So:
> /Projects/Common
> Trunk
> ------|---- Common1
> |---- Common2 ...
> Branches
> Tags
>
> /Projects/AAA
> Trunk
> Branches
> R2
> |----View
> |----Business
> |----DAL
> Tags
>
> The solution contains:
> MySln.sln
> Common1
> Common2
> View
> Business
> DAL
>
> Months go by, and we decide that we want to move R2 and
> associated Common projects into a new repository. How would
> I do that? For that matter, would we be able to maintain a
> Visual Studio solution that referenced two different SVN
> sources as shown above?
>
>
> --
> David Bicking
>
>
> **************************************************************
> ***********
> This communication, including attachments, is for the
> exclusive use of addressee and may contain proprietary,
> confidential and/or privileged information. If you are not
> the intended recipient, any use, copying, disclosure,
> dissemination or distribution is strictly prohibited. If you
> are not the intended recipient, please notify the sender
> immediately by return e-mail, delete this communication and
> destroy all copies.
> **************************************************************
> ***********
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org