You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Sylvain Viart <sy...@easyrencontre.com> on 2007/09/25 13:55:48 UTC
updating to the specified tag?
Hi,
Is it possible to update (not to switch or merge) to the same revision
that were been copied into a tag?
Ex:
trunk_wc/file1 rev 123
trunk_wc/file2 rev 129
Mixed version wc...
now I tag the wc using a copy.
cd ..
svn copy http://url//repos/tags/mytag trunk_wc
Now, I would like to have in the trunk, the same that I've taged in mytag.
ideally something like the :
cd trunk_wc/
svn up -r http://url//repos/tags/mytag
Any idea?
Regards,
Sylvain.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: updating to the specified tag?
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: John Peacock [mailto:john.peacock@havurah-software.org]
> Sent: Wednesday, September 26, 2007 7:17 AM
> To: Sylvain Viart
> Cc: users@subversion.tigris.org
> Subject: Re: updating to the specified tag?
>
> Sylvain Viart wrote:
> > It's for deployment purpose.
> >
> > I've a dedicated trunk wc for deployment, and for now it's
> more that
> > often in mixed version states.
>
> You are really making this much more difficult than it needs
> to be. A tag is merely a copy that represents a collection
> of files at specific revisions; there is *no* requirement
> that all files must be as of the same revision. For that
> matter, you can make a tag based on an existing
> mixed-revision working copy ala
>
> svn cp . http://url/path
>
I agree with John. Also, I do not understand why you (Sylvain) want to
pick files from different revisions of the project. I've never heard of
this practice and don't understand the benefit you gain. To me, any
particular revision should represent exactly what you need to build for
a successful deployment. When I need to make changes specific for a
particular deployment scenario, I create a branch, make those changes,
and deploy from there. More than likely, this is a QA or release branch
anyway, so it needs to be maintained in isolation for at least a while,
then retired.
--
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: updating to the specified tag?
Posted by Erik Huelsmann <eh...@gmail.com>.
On 9/28/07, Sylvain Viart <sy...@easyrencontre.com> wrote:
> Hi,
>
> John Peacock a écrit :
> Sylvain Viart wrote:
> It's for deployment purpose. I've a dedicated trunk wc for deployment, and
> for now it's more that often in mixed version states.
> You are really making this much more difficult than it needs to be. A tag
> is merely a copy that represents a collection of files at specific
> revisions; there is *no* requirement that all files must be as of the same
> revision. For that matter, you can make a tag based on an existing
> mixed-revision working copy ala
> $ svn cp . http://url/path
> In fact I understand this point very well, my initial question was how to
> get all the revision recorded back again in my trunk wc?
$ svn switch http://url/tag/path .
Makes your working copy reflect the state it had when you created the tag.
> And discussing about this seems that I misuse SVN, or I do not make branches
> to work efficiently. I rewrite my proposed svn use:
>
>
> developers use trunk, and commit what ever they need.
> when ready they update part of their changes on the deployment wc (somewhat:
> cd /deploy ; svn up -r myrev or HEAD somefiles)
> if it works as expected, some test are performed on the new code and the wc
> is validated for production
> the wc is copied into a tags and deployed on production server based on that
> new tag (probably a switch or an export or something equivalent (rsync
> +filter))
> the deployment wc is freed but keep its states (here I block with this
> topic)
> END
> if it doesn't work, the deployment wc may be altered by the developer
> testing its code, to match preproduction environment requirement for
> example.
>
> if the changes are slim they are commited in the trunk, they we go at step 3
> if the changes seems too big, the developer must free the deployment wc and
> go back to the DEV aborting its deployment.
> the deployment is aborted the deployment wc must be reverted to its previous
> stable states. somewhat a saved tag, but should be in the trunk?? same as
> 3.2, I block here.
> Your method of tweaking the rev of many files in your "trunk_wc" means
> that there is *no* control over those files.
> In fact, in the deployment wc they're in mixed revision states and
> effectively there's no simple way to switch back to that states.
> Another point to mention, is that edition is expected in the deployment wc.
> So I need to trac modification in that wc as well.
> Another point, I don't want to force commit for deployment purpose if the
> deployment should be aborted next...
>
> If I am understanding your scheme, then I can suggest an alternate one.
> How about I give you the ability to keep any given WC pointing at the most
> current tag [matching a regex], with as much of the tag history maintained
> as you like (so you can roll back to any point in time)? All your developers
> have to do is to create a tag with a predefined (by you) name, and a
> post-commit script will keep that WC in sync automatically.
> Seems interesting, but I don't want to to use commit to test all changes. I
> prefer to have commit restricted to main changes, not to deployment test.
>
> This is particularly good for web site developers because it means that
> there is no need to ever update the production server directly - the
> post-commit script does all of the work for you.
> I've bring one simple solution to this, but may be not the best, is to have
> the wc be on the DEV web server. :-)
> Which for me, is better than to have to commit each time you want to have
> source online. You can only commit stable code.
Ouch. This is probably where you're going wrong: you should commit all
changes, even if (slightly) destabilizing, but not all to trunk. If
you want to refactor code (in a destabilizing way), use a branch.
> I wrote SVN::Notify::Mirror for this precise purpose. One of the most
> powerful capabilities is to match a commit path based on a regular
> expression and switch a WC to this new path. You shouldn't fear switch, it
> is very efficient. It only updates the files that change between rev A and
> rev B, so if you have large WC's, it will only change those specific
> files.
> Here is my proposed development schema:
Reading your proposed schema and the different arguments you're using
for the way you want to work, I'd say you need to start working with a
small project for some time to figure out what works for you. There's
not one truth.
bye,
Erik.
Re: updating to the specified tag?
Posted by John Peacock <jo...@havurah-software.org>.
Sylvain Viart wrote:
> I rewrite my proposed svn use:
>
> 1. developers use trunk, and commit what ever they need.
Excellent.
> 2. when ready they update part of their changes on the deployment wc
> (somewhat: cd /deploy ; svn up -r myrev or HEAD somefiles)
Bad. It means that the deployment server (what I call test server) is not at a
single rev, and hence the totality of this checkout cannot be easily replicated
to some other server. It also means that the deployment server is basically
only able to be messed with by one person at a time (since you don't want to
have multiple people updating multiple, possibly interrelated, files).
> 3. if it works as expected, some test are performed on the new code
> and the wc is validated for production
> 1. the wc is copied into a tags and deployed on production
> server based on that new tag (probably a switch or an export
> or something equivalent (rsync +filter))
> 2. the deployment wc is freed but keep its states (here I block
> with this topic)
> 3. END
Tags good. Switch good. Export bad. The reason is that you now have no idea
what is on the production server, since you have severed it from the version
control system. If you use switch, a simple 'svn info' shows you exactly what
tag the production server is currently at. The overriding goal of an VCS is to
*not* lose information. The only (IMNSHO) good reason to use export is when
building a tarball for distribution (which doesn't sound like what you are
talking about anyways). I'll deal with item 3.2 in the next comment.
> 4. if it doesn't work, the deployment wc may be altered by the
> developer testing its code, to match preproduction environment
> requirement for example.
> * if the changes are slim they are commited in the trunk, they
> we go at step 3
> * if the changes seems too big, the developer must free the
> deployment wc and go back to the DEV aborting its deployment.
Very bad. If you make changes to the deployment WC, small or large, you are
just asking for trouble, because you then have to merge that back to the trunk.
What if, while Developer A is making his changes work on the deployment
machine, Developer B commits her changes to trunk which cause a conflict. Now,
when Dev A is done and happy, he tries to merge the dev branch back to trunk and
hits conflicts that he didn't cause. It is a form of action at a distance and
it is very hard to deal with. If you treat the repository as the One True Code,
then each developer is only responsible for dealing with the conflicts caused by
committing their local changes.
Additionally, it is all too easy to make changes to the deployment server and
then forget to commit them back. And the next person to update the deployment
server then has to deal with them (and may have no clue who made those changes
or even what they mean). Because you are assuming that the developers can
update an single file to a given rev, it may be weeks before anyone does a full
update and discovers massive breakage because the WC as a hole is inconsistent.
And forgotten updates can fester for weeks or months if you never perform a
full update at all.
> 5. the deployment is aborted the deployment wc must be reverted to
> its previous stable states. somewhat a saved tag, but should be in
> the trunk?? same as 3.2, I block here.
Again, if the deployment server is simply a checkout of trunk (or branch) it is
trivial to revert changes back to the last stable state, but only if you haven't
made any local (to the deployment server) changes.
I don't know what your workflow is like. You haven't said how many developers
you have working on the project, how often you have destabalizing changes
committed, how often two developers will be working on the same section of code,
how long it typically takes a developer to write a "change", or really what kind
of project you are talking about. I can't make more detailed recommendations
without much more information.
But I can tell you what works for us, based on our workflow of a number of
basically independent websites in a single repository, with only occasional
developer overlap:
- All commits are made to trunk except for large reorganization/rewrites which
happen in a branch;
- The test server is always up to date with trunk (except when a large branch is
in progress, where it is always up to date with that branch);
- The test site is allowed to break and the person who broke it is typically
responsible for fixing it;
- If this is an executable application as opposed to a web site, it is a very
good thing to have a buildbot (or as many as you have targeted platforms) that
is constantly building the latest rev and running your test suite (this is now
called "continuous integration");
- The production server is always pointing at the most recent tag;
- No changes are allowed to tags (if a problem is detected, fix it quick and
create a new tag).
HTH
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: updating to the specified tag?
Posted by Sylvain Viart <sy...@easyrencontre.com>.
Hi,
John Peacock a écrit :
> Sylvain Viart wrote:
>
>> It's for deployment purpose.
>>
>> I've a dedicated trunk wc for deployment, and for now it's more that
>> often in mixed version states.
>>
>
> You are really making this much more difficult than it needs to be. A tag is
> merely a copy that represents a collection of files at specific revisions; there
> is *no* requirement that all files must be as of the same revision. For that
> matter, you can make a tag based on an existing mixed-revision working copy ala
>
> svn cp . http://url/path
>
In fact I understand this point very well, my initial question was how
to get all the revision recorded back again in my trunk wc?
And discussing about this seems that I misuse SVN, or I do not make
branches to work efficiently.
I rewrite my proposed svn use:
1. developers use trunk, and commit what ever they need.
2. when ready they update part of their changes on the deployment wc
(somewhat: cd /deploy ; svn up -r myrev or HEAD somefiles)
3. if it works as expected, some test are performed on the new code
and the wc is validated for production
1. the wc is copied into a tags and deployed on production
server based on that new tag (probably a switch or an export
or something equivalent (rsync +filter))
2. the deployment wc is freed but keep its states (here I block
with this topic)
3. END
4. if it doesn't work, the deployment wc may be altered by the
developer testing its code, to match preproduction environment
requirement for example.
* if the changes are slim they are commited in the trunk, they
we go at step 3
* if the changes seems too big, the developer must free the
deployment wc and go back to the DEV aborting its deployment.
5. the deployment is aborted the deployment wc must be reverted to
its previous stable states. somewhat a saved tag, but should be in
the trunk?? same as 3.2, I block here.
> Your method of tweaking the rev of many files in your "trunk_wc" means that
> there is *no* control over those files.
In fact, in the deployment wc they're in mixed revision states and
effectively there's no simple way to switch back to that states.
Another point to mention, is that edition is expected in the deployment
wc. So I need to trac modification in that wc as well.
Another point, I don't want to force commit for deployment purpose if
the deployment should be aborted next...
> If I am understanding your scheme, then I can suggest an alternate one. How
> about I give you the ability to keep any given WC pointing at the most current
> tag [matching a regex], with as much of the tag history maintained as you like
> (so you can roll back to any point in time)? All your developers have to do is
> to create a tag with a predefined (by you) name, and a post-commit script will
> keep that WC in sync automatically.
Seems interesting, but I don't want to to use commit to test all
changes. I prefer to have commit restricted to main changes, not to
deployment test.
> This is particularly good for web site
> developers because it means that there is no need to ever update the production
> server directly - the post-commit script does all of the work for you.
>
I've bring one simple solution to this, but may be not the best, is to
have the wc be on the DEV web server. :-)
Which for me, is better than to have to commit each time you want to
have source online. You can only commit stable code.
> I wrote SVN::Notify::Mirror for this precise purpose. One of the most powerful
> capabilities is to match a commit path based on a regular expression and switch
> a WC to this new path. You shouldn't fear switch, it is very efficient. It
> only updates the files that change between rev A and rev B, so if you have large
> WC's, it will only change those specific files.
>
> Here is my proposed development schema:
>
> 1) All normal development happens on trunk (though you can just as easily use
> branches)
>
> 2) Any testing server you have always tracks trunk using a post-commit script
>
> 3) The production server always tracks the latest tag that matches some regex,
> say RELEASE-YYYYMMDDSEQ, also using the same post-commit script.
>
>
does it mean your developers need to commit all change, each time, to go
from step 1 => 2 ?
Thanks for your suggestions.
I'm still thinking about a nice way of having test and revert on the
preproduction stage.
Sylvain.
Re: updating to the specified tag?
Posted by John Peacock <jo...@havurah-software.org>.
Sylvain Viart wrote:
> It's for deployment purpose.
>
> I've a dedicated trunk wc for deployment, and for now it's more that
> often in mixed version states.
You are really making this much more difficult than it needs to be. A tag is
merely a copy that represents a collection of files at specific revisions; there
is *no* requirement that all files must be as of the same revision. For that
matter, you can make a tag based on an existing mixed-revision working copy ala
svn cp . http://url/path
Your method of tweaking the rev of many files in your "trunk_wc" means that
there is *no* control over those files. In other words, if the server holding
"trunk_wc" were to fail, there would be no easy way to recreate that set of
files. This kind of scheme is completely ignoring the strengths of version
control. You might as well be copying the files up manually every time using
'svn cat'. You are literally keeping an unversioned collection of files on
disk; each files itself is versioned, but the *collection* itself is completely
random and not tracked.
If I am understanding your scheme, then I can suggest an alternate one. How
about I give you the ability to keep any given WC pointing at the most current
tag [matching a regex], with as much of the tag history maintained as you like
(so you can roll back to any point in time)? All your developers have to do is
to create a tag with a predefined (by you) name, and a post-commit script will
keep that WC in sync automatically. This is particularly good for web site
developers because it means that there is no need to ever update the production
server directly - the post-commit script does all of the work for you.
I wrote SVN::Notify::Mirror for this precise purpose. One of the most powerful
capabilities is to match a commit path based on a regular expression and switch
a WC to this new path. You shouldn't fear switch, it is very efficient. It
only updates the files that change between rev A and rev B, so if you have large
WC's, it will only change those specific files.
Here is my proposed development schema:
1) All normal development happens on trunk (though you can just as easily use
branches)
2) Any testing server you have always tracks trunk using a post-commit script
3) The production server always tracks the latest tag that matches some regex,
say RELEASE-YYYYMMDDSEQ, also using the same post-commit script.
Here is your postcommit file (using SVN::Notify::Config):
#!/usr/bin/perl -MSVN::Notify::Config=$0
--- #YAML:1.0
'':
PATH: "/usr/bin:/usr/local/bin"
'project/trunk':
handler: Mirror
minimal: 1
to: "/path/to/www/htdocs"
'project/tags':
handler: Mirror::SSH
tag-regex: "^RELEASE-"
to: "/path/to/remote/www/htdocs"
ssh-host: "remote_host"
ssh-user: "remote_user"
ssh-identity: "/home/user/.ssh/id_rsa"
That file constitutes both the data and the post-commit script in one. It keeps
the local directory "/path/to/www/htdocs" in sync with the trunk at all times.
It keeps the remote diretory "/path/to/remote/www/htdocs" in sync with the
latest tag that matches the string "^RELEASE-" (full Perl regex capabilities).
Additionally, the remote server is updated using a specific ssh user/key.
Does this seem like it does what you want?
HTH
John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: updating to the specified tag?
Posted by Sylvain Viart <sy...@easyrencontre.com>.
Hi,
*From:* Hari Kodungallur
> On 9/25/07, *Sylvain Viart* wrote:
>
> Hi,
>
> Is it possible to update (not to switch or merge) to the same revision
> that were been copied into a tag?
>
> The only way to update the trunk_wc is to update the files in the
> trunk in the repository. This can be achieved only using copying files
> to trunk or merging to trunk.
>
> In this particular case though, you created the tag using the
> trunk_wc. So, updating the trunk_wc using the tag (even if
> hypothetically it was possible) would yield the same set of files,
> isn't it?
Not really, it alters the wc. svn st not empty, many added modified
files, etc. But you're right, the files are probably the same.
switching also alters the wc, and next the wc will not be on trunk anymore.
Bicking, David (HHoldings, IT) a écrit :
> What is the reason you want to update your workspace to a particular
> revision without it affecting the repository or switching to it?
> Perhaps it is to do a build?
It's for deployment purpose.
I've a dedicated trunk wc for deployment, and for now it's more that
often in mixed version states.
ex:
554 deploy/file1
554 deploy/file2
554 deploy/file3
554 deploy/file4
554 deploy/dir2/file5
559 deploy/dir2/file6
554 deploy/dir2/file7
557 deploy/file8
554 deploy/file9
May be I try to misuse svn... But in this context:
I've updated (svn up) only the "deploy/dir2/file6" bringing it to
revision 559.
Now I would like to take a snapshot of all revision listed here, of
course I've much more file...
What I would like to do is a bit like David said:
> Your options are:
> 1. "rollback" to revision, which is a reverse merge from HEAD to the
> desired revision. This makes your Trunk HEAD match the tag, which is
> NOT what you porport to desire.
No, because it alters the wc.
I would like to "rollback" this way :
cd deploy
svn up -r 544 .
svn up -r 557 deploy/file8
svn up -r559 deploy/dir2/file6
Now I've the wc, unmodified (svn st empty), still on trunk, and somewhat
matching the revision snapshot.
If I remember well this can be achieved with CVS tags?
cvs up -r tags
> 2. (using TSVN) "revert to revision" by right-clicking on the revision
> while in the log and chosing the option. This pulls that revision
> down to your workspace w/o affecting the repository until you commit.
Yes with only one revision, not a mixed set of revision.
I'm using svn linux command line client.
> I'm sure there is at least one other way to get the desired result.
> Item 2 looks like what you seek, and you can later "update" to get the
> HEAD and continue like normal. Personally, if I wanted to get the
> tag, I'd just switch to the TAG, do my build or whatever, then switch
> back to trunk, which is essentially the equivalent of option #2, but
> much easier.
You're on the way. :-)
Effectively if I want to update some files, so I only have to svn up -r
rev any file I want from the trunk. Especially, that way, I'm also able
to trac change in the deployment wc. svn st is still empty.
May be it's not the intended use of SVN, but how can I achieve that?
Regards,
Sylvain.
RE: Re: updating to the specified tag?
Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
What is the reason you want to update your workspace to a particular
revision without it affecting the repository or switching to it?
Perhaps it is to do a build?
Your options are:
1. "rollback" to revision, which is a reverse merge from HEAD to the
desired revision. This makes your Trunk HEAD match the tag, which is NOT
what you porport to desire.
2. (using TSVN) "revert to revision" by right-clicking on the revision
while in the log and chosing the option. This pulls that revision down
to your workspace w/o affecting the repository until you commit.
I'm sure there is at least one other way to get the desired result.
Item 2 looks like what you seek, and you can later "update" to get the
HEAD and continue like normal. Personally, if I wanted to get the tag,
I'd just switch to the TAG, do my build or whatever, then switch back to
trunk, which is essentially the equivalent of option #2, but much
easier.
--
David
________________________________
From: Hari Kodungallur [mailto:hkodungallur@gmail.com]
Sent: Tuesday, September 25, 2007 1:13 PM
To: Sylvain Viart
Cc: users@subversion.tigris.org
Subject: Re: updating to the specified tag?
On 9/25/07, Sylvain Viart <sy...@easyrencontre.com>
wrote:
Hi,
Is it possible to update (not to switch or merge) to the
same revision
that were been copied into a tag?
The only way to update the trunk_wc is to update the files in
the trunk in the repository. This can be achieved only using copying
files to trunk or merging to trunk.
In this particular case though, you created the tag using the
trunk_wc. So, updating the trunk_wc using the tag (even if
hypothetically it was possible) would yield the same set of files, isn't
it?
Thanks,
-Hari Kodungallur
*************************************************************************
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.
*************************************************************************
Re: updating to the specified tag?
Posted by Hari Kodungallur <hk...@gmail.com>.
On 9/25/07, Sylvain Viart <sy...@easyrencontre.com> wrote:
>
> Hi,
>
> Is it possible to update (not to switch or merge) to the same revision
> that were been copied into a tag?
>
> Ex:
>
> trunk_wc/file1 rev 123
> trunk_wc/file2 rev 129
>
> Mixed version wc...
>
> now I tag the wc using a copy.
>
> cd ..
> svn copy http://url//repos/tags/mytag trunk_wc
>
> Now, I would like to have in the trunk, the same that I've taged in mytag.
>
> ideally something like the :
>
>
> cd trunk_wc/
> svn up -r http://url//repos/tags/mytag
>
> Any idea?
The only way to update the trunk_wc is to update the files in the trunk in
the repository. This can be achieved only using copying files to trunk or
merging to trunk.
In this particular case though, you created the tag using the trunk_wc. So,
updating the trunk_wc using the tag (even if hypothetically it was possible)
would yield the same set of files, isn't it?
Thanks,
-Hari Kodungallur
RE: updating to the specified tag?
Posted by "Brummer, Byron" <By...@LiveNation.com>.
Sylvain Viart [mailto:sylvain.viart@easyrencontre.com] wrote:
> Is it possible to update (not to switch or merge) to the same revision
> that were been copied into a tag?
> Ex:
> trunk_wc/file1 rev 123
> trunk_wc/file2 rev 129
> Mixed version wc...
> now I tag the wc using a copy.
> cd ..
> svn copy http://url//repos/tags/mytag trunk_wc
> Now, I would like to have in the trunk, the same that I've taged in
mytag.
> ideally something like the :
> cd trunk_wc/
> svn up -r http://url//repos/tags/mytag
> Any idea?
Yes, it is possible, however SVN's design forces you to jump
through
a mess of pain to get there. Thankfully you can script it to
some
degree, with effort.
A tag is really a copy and results in a new revision with shared
history. But you don't want that one, you want what it
represents (a
particular path@rev on a particular branch or trunk).
First checkout the latest of whatever branch you're talking
about
(assuming you haven't deleted it...at which point this becomes
much
more complex because of how badly SVN handles deleted objects).
Now that you have HEAD on the branch the tag was made, you need
to
run svn diff --summarize between your copy and the tag you're
trying
to get to. This will give you a manifest of the files that need
to be
changed.
Walk this manifest and one by one retrieve the history of that
file on the tag path and walk the history backwards until the
path is
no longer on the /tag/. This is probably the 2nd entry from the
top of the log, but might not be if you've changed anything on
the
tag after it was created or if the tag was created by copying
another
tag (i.e., copying a build # tag to a final release # tag).
Now you have the original path and rev. Use that rev to update
the
particular file. Do this separately for each file in the diff
manifest...one by one.
If you need to REMOVE a file because it exists at HEAD but not
at
the tag you're trying to reproduce, you can't update to a
revision
number. -If you try, such as update -r 0, it will remove the
file in
your wc...but it'll screw up that file's parent directory meta
info
such that SVN won't let you copy your WC (you can't tag again).
Instead you need to kluge around this SVN brain damage by running
svn switch on the file to a URL that doesn't exist:
svn switch http://my/repo/NON_EXISTANT_PATH
wc/path/to/file
This will remove the file from your wc w/o screwing up the
directory's
meta data allowing you to copy your wc again if you'd like the
same
as it originally existed. -In this case you're leveraging SVN's
poor deleted file handling in your favor instead of against you.
I have scripts I use to do this, but the code is part of
larger utilities and I haven't had time to split it out cleanly
yet.
It is a major feature hole/design flaw in SVN. SVN needs *real*
tags, not kluged copy. It also needs the Last Modified Revision
to be correct...which it frequently is not (found out the hard
way).
HTH
-Byron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org