You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Hendrik Schober <Sp...@gmx.de> on 2007/04/05 11:36:09 UTC
Re: CVS to SVN, best practice
Bob Hiestand <bo...@gmail.com> wrote:
> On 2/8/07, Hendrik Schober <Sp...@gmx.de> wrote:
>
> > > [...]
> > > Recall that externals can point at different repositories just as
> > > easily as they can the same repository. You can't have an atomic
> > > commit against more than one repository.
> > > [...]
> >
> > Ugh. What now?
> > We'd /really/ like to switch to svn. Hwoever, we would
> > need some way to use it so that it fits our needs, not
> > the other way around.
> > Lemme recap:
> >
> > We have several projects considerable parts of which
> > are shared between them. Developers are hacking away
> > on those projects including the shared code, and have
> > to check in changes in the shared parts as well as in
> > the project-specific parts of the code. When projects
> > get tagged, the shared parts should get the same tag.
I'm sorry following up has taken me so long. There's
been a bit of Real Life (TM) here interfering with
plans...
> Hendrik,
>
> I would personally develop your shared components separately and
> rely on your build procedure to pull the correct compiled version.
> Treat them as libraries maintained by a third party and enforce a
> higher level of change control on them.
I don't think this is going to work. All our
products use many of these components and they
are fixed and enhanced during work in those
projects they are used in. Having to maintain
them seperately would be a PITA. (Just think
about tagging.)
> If the above is unpalatable, I would maintain tags and branches
> across your entire repository so that everything gets tagged together,
> and not use externals at all.
This would be a PITA as well. I just counted
>50 top-level folders under "projects", >60
under "3rdparty" and another ~30 in "shared".
If I wanted to tag "projects/project1" using
this scheme I'd have to manually delete >100
folders within the tag folder, trying to avoid
to delete anything that's used on any of the
halve a dozen platforms some of our projects
are ported to. Sounds like a certain receipt
for desaster...
Thanks anyway.
I was hoping someone could suggest a slightly
different process we could use for our
development, but it seems that SVN in its
current state isn't going to work for us.
Which is sad, as it's got a few features
(like renaming) we'd really like to have.
If anyone still has any ideas how we could
proceed, I'd really like to hear from you.
(See
news://news.gmane.org/epvkvq$4oo$1@sea.gmane.org
news://news.gmane.org/eq76j6$oc3$1@sea.gmane.org
again for a detailed explanation.)
(Oh, and here's another question: Do you think
it's worth to explain the problem on the
developer's list, too?)
> Bob
Schobi
--
SpamTrap@gmx.de is never read
I'm HSchober at gmx dot org
"My hope is that if more people start reading books,
the world will become a better place."
froarulv in afp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS to SVN, best practice
Posted by Jing Xue <ji...@digizenstudio.com>.
Quoting BRM <bm...@yahoo.com>:
> So where my Makefile use to look like:
>
> PROJ_TCP = projTCP
> PROJ_TCP_RELEASE = PROJTCP_1_1
> ...
> sharedTCP: projTCP/
> cvs export $(PROJ_TCP) -r $(PROJ_TCP_RELEASE)
> ...
>
> I'll now have to do something like:
>
> PROJ_TCP = https://my.svn.server/projTCP/release/projTCP_1_1/
> ...
> sharedTCP: projTCP/
> svn export $(PROJ_TCP)
> ...
Why not:
SCM_ROOT = https://my.svn.server
PROJ_TCP = projTCP
PROJ_TCP_RELEASE = PROJTCP_1_1
...
sharedTCP: projTCP/
svn export $(SCM_ROOT)/$(PROJ_TCP)/release/$(PROJ_TCP_RELEASE)
As long as you stick to whatever convention you come up with,
logically, you'd still be concerned with the same concepts as before,
namely the server (which I presume you had an implicit CVSROOT), the
project name and the target release/tag.
--
Jing Xue
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS to SVN, best practice
Posted by BRM <bm...@yahoo.com>.
--- Bob Hiestand <bo...@gmail.com> wrote:
> On 4/6/07, Hendrik Schober <Sp...@gmx.de> wrote:
> > > If you can modify shared code during release of any of the
> sharing
> > > project, I believe you will see many other problems that have
> nothing
> > > to do with the version control software.
> > Why?
> I've worked in two environments that did this. Both ended up
> changing
> to a better managed approach to modifying shared code. The problem
> is
> that it is very, very easy to make bad changes to shared code when
> it
> is embedded into project source trees. The problems come in a number
> of ways, such as project-specific code slipping into the shared area
> or incompatible changes being made to the shared API that isn't found
> until much later (during an unrelated project build).
>
> Overall, it is a lessening of the boundaries between modules and
> makes
> it easy for too many and incorrect dependencies to develop.
If I may add 2 cents here...
I do something similar at home, but not the way that Mr. Schober is
describing. I have a number of projects for shared sources, and a
number of other projects that use them. For example, one project is a
TCP Class for C++ that I use all over the place, and another project is
a program that needs to use TCP comms to send data. For this discussion
I'll call it projTCP and projA.
While I've been using SVN at work for almost 3 years now, I am just
getting around to converting my home setup from CVS to SVN. Under CVS I
used tags to release each project. So projTCP would have a release of
PROJTCP_1_1; and then projA would have some special lines in its
Makefile that would export the specific release PROJTCP_1_1. All the
Makefile needed to know was (a) where to find the repository, and (b)
what release to use.
Why did I do this? As another poster described, whoever maintains
projTCP could go off and rewrite projTCP's API or do something that
breaks how projA works. If I want to maintain configuration management
on projA, then projA needs to only work with a specific release of
projTCP; that way projA will always work as long as it has that version
of projTCP. If there was a new release of projTCP (say PROJTCP_1_2)
then I could update the Makefile in projA to use the new release, and
verify that projA still worked.
You are basically doing something very similar with a script that works
on all the platforms you are supporting.
Now, as I convert my projects over to SVN, I'll have to go in an update
the Makefiles to do this how SVN works over CVS. So, I will have to
specify full paths instead of project and release.
So where my Makefile use to look like:
PROJ_TCP = projTCP
PROJ_TCP_RELEASE = PROJTCP_1_1
...
sharedTCP: projTCP/
cvs export $(PROJ_TCP) -r $(PROJ_TCP_RELEASE)
...
I'll now have to do something like:
PROJ_TCP = https://my.svn.server/projTCP/release/projTCP_1_1/
...
sharedTCP: projTCP/
svn export $(PROJ_TCP)
...
Any how...just my 2 cents.
BRM
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS to SVN, best practice
Posted by Bob Hiestand <bo...@gmail.com>.
On 4/6/07, Hendrik Schober <Sp...@gmx.de> wrote:
> > If you can modify shared code during release of any of the sharing
> > project, I believe you will see many other problems that have nothing
> > to do with the version control software.
>
> Why?
I've worked in two environments that did this. Both ended up changing
to a better managed approach to modifying shared code. The problem is
that it is very, very easy to make bad changes to shared code when it
is embedded into project source trees. The problems come in a number
of ways, such as project-specific code slipping into the shared area
or incompatible changes being made to the shared API that isn't found
until much later (during an unrelated project build).
Overall, it is a lessening of the boundaries between modules and makes
it easy for too many and incorrect dependencies to develop.
Given that it is the way you're set up, however:
> > Tagging isn't an issue. If you chose to not maintain separate release
> > cycles for shared code, that works fine by using global repository
> > tags across a single repository containing all the source (shared
> > modules and individual projects). That way you can tag the repository
> > using project-specific tags to pull back both the state of the project
> > as well as that of the shared code.
>
> So far, so good.
>
> > There is no reason to delete anything from the tags.
>
> Except that nobody wants to checkout the whole
> repository if all they need is "project1" at
> tag "X", you mean? AFAIK, ATM that's several GB,
> so this is not going to work.
Why would you check out the whole repository? You can tag the
repository without having it checked out. You can then check out only
the project you want, under a given tag. There is no need to pull the
repository anywhere.
svn copy -r 123 svn://repo/trunk svn://repo/tags/projectA/release3
svn co svn://repo/tags/projectA/release3 projectA-release3
> > Thank you,
>
> Well, I'm not sure what for. :)
Too many years writing emails at work. It's a well-formed habit.
Thank you, (see?)
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS to SVN, best practice
Posted by Hendrik Schober <Sp...@gmx.de>.
Bob Hiestand <bo...@gmail.com> wrote:
> On 4/5/07, Hendrik Schober <Sp...@gmx.de> wrote:
>
> > > I would personally develop your shared components separately and
> > > rely on your build procedure to pull the correct compiled version.
> > > Treat them as libraries maintained by a third party and enforce a
> > > higher level of change control on them.
> >
> > I don't think this is going to work. All our
> > products use many of these components and they
> > are fixed and enhanced during work in those
> > projects they are used in. Having to maintain
> > them seperately would be a PITA. (Just think
> > about tagging.)
>
> If you can modify shared code during release of any of the sharing
> project, I believe you will see many other problems that have nothing
> to do with the version control software.
Why?
> > > If the above is unpalatable, I would maintain tags and branches
> > > across your entire repository so that everything gets tagged together,
> > > and not use externals at all.
> >
> > This would be a PITA as well. I just counted
> > >50 top-level folders under "projects", >60
> > under "3rdparty" and another ~30 in "shared".
> > If I wanted to tag "projects/project1" using
> > this scheme I'd have to manually delete >100
> > folders within the tag folder, trying to avoid
> > to delete anything that's used on any of the
> > halve a dozen platforms some of our projects
> > are ported to. Sounds like a certain receipt
> > for desaster...
>
> Tagging isn't an issue. If you chose to not maintain separate release
> cycles for shared code, that works fine by using global repository
> tags across a single repository containing all the source (shared
> modules and individual projects). That way you can tag the repository
> using project-specific tags to pull back both the state of the project
> as well as that of the shared code.
So far, so good.
> There is no reason to delete anything from the tags.
Except that nobody wants to checkout the whole
repository if all they need is "project1" at
tag "X", you mean? AFAIK, ATM that's several GB,
so this is not going to work.
> If it appeals,
> you can even introduce some specific naming standards into your
> tagging directory by having something like:
>
> /
> /trunk
> /tags
> /tags/projects
> /tags/projects/projectA
> /tags/projects/projectB
>
> etc.
Yep, that's what I thought, too.
> Thank you,
Well, I'm not sure what for. :)
(But I have to thank everybody here for your patience
with my problem.)
> Bob
Schobi
--
SpamTrap@gmx.de is never read
I'm HSchober at gmx dot org
"My hope is that if more people start reading books,
the world will become a better place."
froarulv in afp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS to SVN, best practice
Posted by Bob Hiestand <bo...@gmail.com>.
On 4/5/07, Hendrik Schober <Sp...@gmx.de> wrote:
> > I would personally develop your shared components separately and
> > rely on your build procedure to pull the correct compiled version.
> > Treat them as libraries maintained by a third party and enforce a
> > higher level of change control on them.
>
> I don't think this is going to work. All our
> products use many of these components and they
> are fixed and enhanced during work in those
> projects they are used in. Having to maintain
> them seperately would be a PITA. (Just think
> about tagging.)
If you can modify shared code during release of any of the sharing
project, I believe you will see many other problems that have nothing
to do with the version control software.
> > If the above is unpalatable, I would maintain tags and branches
> > across your entire repository so that everything gets tagged together,
> > and not use externals at all.
>
> This would be a PITA as well. I just counted
> >50 top-level folders under "projects", >60
> under "3rdparty" and another ~30 in "shared".
> If I wanted to tag "projects/project1" using
> this scheme I'd have to manually delete >100
> folders within the tag folder, trying to avoid
> to delete anything that's used on any of the
> halve a dozen platforms some of our projects
> are ported to. Sounds like a certain receipt
> for desaster...
Tagging isn't an issue. If you chose to not maintain separate release
cycles for shared code, that works fine by using global repository
tags across a single repository containing all the source (shared
modules and individual projects). That way you can tag the repository
using project-specific tags to pull back both the state of the project
as well as that of the shared code.
There is no reason to delete anything from the tags. If it appeals,
you can even introduce some specific naming standards into your
tagging directory by having something like:
/
/trunk
/tags
/tags/projects
/tags/projects/projectA
/tags/projects/projectB
etc.
Thank you,
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS to SVN, best practice
Posted by Les Mikesell <le...@gmail.com>.
Hendrik Schober wrote:
> The project I'm currently working on has ~75
> folders. ~25 of these folders are checked out
> shared stuff, ~25 are 3rd-party stuff (mostly
> exported, so it's rather irrelevant here),
> the rest is specific to the project. If I check
> the project out, I get a script, too, which,
> when run, pulls all the 3rd-party and shared
> stuff.
If you use a script approach to get the components, why does it matter
which are external or what layout you use? You could make a project
that contained nothing but externals references to get all the parts you
need.
>> You'd have to include how your workflow really goes with cvs. I don't
>> see how you can edit shared components without being 'aware' that they
>> are shared and affect other projects.
>
> When I work on something, I certainly know whether
> this is project-specific or shared stuff.
You've glossed over how you deal with the issue of which rev of which
shared component you must use with which rev of each project. With CVS,
even though you can tag things that land in subdirectories in one step,
you still have to go through the contortions of getting the right
versions loaded into your working copy in the first place unless you are
lucky enough that everything works with HEAD revisions. The tag is only
going to help hold the set together if someone wants an exact copy. It
doesn't help as you advance to new revisions and it doesn't help
coordinate changes that affect other projects.
> It's just
> that, for example, I don't know the shared stuff
> that's exclusively used on some other platform. I
> never need to change it, I don't know what it is,
> and right now I don't need to care when I tag.
But that's the only time you don't need to care. When you want to make
changes you do have to care.
>> Given that, why is the concept of
>> using externals tied to tagged revs and separate commits to the shared
>> components that much harder?
>
> I don't think there was that many stuff we "invented"
> as shared stuff. Usually code from some project gets
> lifted to "shared". The point is, by then it's already
> established that it's usueful outside its original
> context, but it might be far from done. Also, while it
> might be done enough for the original context, there
> might be more work to do to make it fit for other
> projects. So the shared stuff often is constantly
> worked on.
> That's where our current taggin scheme fits in nicely:
> I just tag it along with the project I use it in.
But how do you get an appropriate version to start with?
> This way everybody can happily hack away on the shared
> thingies I'm using, while I'm sure that, for release X
> of my project I get the exact state at release X of any
> shared stuff I use without having to create a release
> of every shared thingy I'm using.
You'd have that with externals pegged to revision numbers if you wanted
that. The harder part is that sometimes you want the improvements that
have been made in shared components (or even need them) and sometimes
you don't. That's the hard part, and it isn't affected that much by
losing the ability to ignore it and tag everything at once.
>> You must have similar operations handled by
>> your build scripts now.
>
> I'm not sure what operations you're referring to here.
> The build script for "project1" currently checks out
> "project1", executes the checkout script that came with
> it (which checks out all shared and exports all 3rdparty
> stuff), and updates to the tag specified. Then it triggers
> the build.
How does this script decide which rev of each thing it needs? And how
did the stuff get assembled before the tag was applied?
>> On the other hand there has been a long
>> discussion here about how cvs tagging differs from svn and perhaps you
>> have the use case to clarify what is missing.
>
> What we would need is that we could tag a mixture of
> modules from seperate places checked out into the same
> folder on the local disk with the same tag. I honestly
> have no idea how this could be done with SVN's tagging
> scheme. -- Which is why I asked whether there's a different
> way for us to do what we do now.
Your top level project would have external references to the shared and
third party components you want to pull in. While you are developing,
you might want to make branch copies of anything you expect to change so
your externals can reference the branch HEAD and you can have a script
that goes into each and commits without bothering anything else. You
could script tag copies of everything if necessary - but if you have
your own branch you probably can just work/build/test against the branch
head. When you are ready for a release, you'd copy each of the external
modules to a tag and adjust the external references - and merge the
changes back to the trunk.
--
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: CVS to SVN, best practice
Posted by Hendrik Schober <Sp...@gmx.de>.
Les Mikesell <le...@gmail.com> wrote:
> Hendrik Schober wrote:
> > > >
> > > > We have several projects considerable parts of which
> > > > are shared between them. Developers are hacking away
> > > > on those projects including the shared code, and have
> > > > to check in changes in the shared parts as well as in
> > > > the project-specific parts of the code. When projects
> > > > get tagged, the shared parts should get the same tag.
> > >
> > > I would personally develop your shared components separately and
> > > rely on your build procedure to pull the correct compiled version.
> > > Treat them as libraries maintained by a third party and enforce a
> > > higher level of change control on them.
> >
> > I don't think this is going to work. All our
> > products use many of these components and they
> > are fixed and enhanced during work in those
> > projects they are used in. Having to maintain
> > them seperately would be a PITA. (Just think
> > about tagging.)
>
> What about tagging? Don't you want your choice of what rev of shared
> component builds with each project? You have to maintain that
> somewhere. Why is the external link harder than anywhere else?
My working copy looks like this:
project1
|
+-prj1_stuff1
|
+-prj1_stuff2
|
+-shared1
|
+-shared2
|
+-3rdparty1
|
+-3rdparty2
With CVS, if I throw a tag on "project1", I also
tag all the shared and 3rd-party stuff. That's
good, as it allows us to get all the components
specific at this tag.
If I throw a tag in SVN, shared and 3rd-party
stuff isn't affected. That's bad, as it requires
that whoever throws the tag modifies all the
externals beforehand, so that they are nailed
to a specific revision, too.
The project I'm currently working on has ~75
folders. ~25 of these folders are checked out
shared stuff, ~25 are 3rd-party stuff (mostly
exported, so it's rather irrelevant here),
the rest is specific to the project. If I check
the project out, I get a script, too, which,
when run, pulls all the 3rd-party and shared
stuff. This project is compiled in several
configurations (library, command line app,
plugin for other app etc.) on OSX, Windows,
and several Unices, all in all about halve a
dozen platforms.
Consider this: If I have fixed a bug on Windows
I throw a tag so that all configurations on all
platforms can be built. So I throw a tag on my
whole working copy. The build servers will
checkout the project, run the script, update
to my tag, and have exactly the right version.
> > > If the above is unpalatable, I would maintain tags and branches
> > > across your entire repository so that everything gets tagged together,
> > > and not use externals at all.
> >
> > This would be a PITA as well. I just counted
> > >50 top-level folders under "projects", >60
> > under "3rdparty" and another ~30 in "shared".
> > If I wanted to tag "projects/project1" using
> > this scheme I'd have to manually delete >100
> > folders within the tag folder, trying to avoid
> > to delete anything that's used on any of the
> > halve a dozen platforms some of our projects
> > are ported to. Sounds like a certain receipt
> > for desaster...
>
> If you use the 'check out the whole thing' approach [...]
We don't.
> > I was hoping someone could suggest a slightly
> > different process we could use for our
> > development, but it seems that SVN in its
> > current state isn't going to work for us.
> > Which is sad, as it's got a few features
> > (like renaming) we'd really like to have.
> >
> > If anyone still has any ideas how we could
> > proceed, I'd really like to hear from you.
> > (See
> > news://news.gmane.org/epvkvq$4oo$1@sea.gmane.org
> > news://news.gmane.org/eq76j6$oc3$1@sea.gmane.org
> > again for a detailed explanation.)
> >
> > (Oh, and here's another question: Do you think
> > it's worth to explain the problem on the
> > developer's list, too?)
>
> You'd have to include how your workflow really goes with cvs. I don't
> see how you can edit shared components without being 'aware' that they
> are shared and affect other projects.
When I work on something, I certainly know whether
this is project-specific or shared stuff. It's just
that, for example, I don't know the shared stuff
that's exclusively used on some other platform. I
never need to change it, I don't know what it is,
and right now I don't need to care when I tag.
> Given that, why is the concept of
> using externals tied to tagged revs and separate commits to the shared
> components that much harder?
I don't think there was that many stuff we "invented"
as shared stuff. Usually code from some project gets
lifted to "shared". The point is, by then it's already
established that it's usueful outside its original
context, but it might be far from done. Also, while it
might be done enough for the original context, there
might be more work to do to make it fit for other
projects. So the shared stuff often is constantly
worked on.
That's where our current taggin scheme fits in nicely:
I just tag it along with the project I use it in.
This way everybody can happily hack away on the shared
thingies I'm using, while I'm sure that, for release X
of my project I get the exact state at release X of any
shared stuff I use without having to create a release
of every shared thingy I'm using.
> You must have similar operations handled by
> your build scripts now.
I'm not sure what operations you're referring to here.
The build script for "project1" currently checks out
"project1", executes the checkout script that came with
it (which checks out all shared and exports all 3rdparty
stuff), and updates to the tag specified. Then it triggers
the build.
> On the other hand there has been a long
> discussion here about how cvs tagging differs from svn and perhaps you
> have the use case to clarify what is missing.
What we would need is that we could tag a mixture of
modules from seperate places checked out into the same
folder on the local disk with the same tag. I honestly
have no idea how this could be done with SVN's tagging
scheme. -- Which is why I asked whether there's a different
way for us to do what we do now.
Schobi
--
SpamTrap@gmx.de is never read
I'm HSchober at gmx dot org
"My hope is that if more people start reading books,
the world will become a better place."
froarulv in afp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS to SVN, best practice
Posted by Les Mikesell <le...@gmail.com>.
Hendrik Schober wrote:
>>>
>>> We have several projects considerable parts of which
>>> are shared between them. Developers are hacking away
>>> on those projects including the shared code, and have
>>> to check in changes in the shared parts as well as in
>>> the project-specific parts of the code. When projects
>>> get tagged, the shared parts should get the same tag.
>>
>> I would personally develop your shared components separately and
>> rely on your build procedure to pull the correct compiled version.
>> Treat them as libraries maintained by a third party and enforce a
>> higher level of change control on them.
>
> I don't think this is going to work. All our
> products use many of these components and they
> are fixed and enhanced during work in those
> projects they are used in. Having to maintain
> them seperately would be a PITA. (Just think
> about tagging.)
What about tagging? Don't you want your choice of what rev of shared
component builds with each project? You have to maintain that
somewhere. Why is the external link harder than anywhere else?
>> If the above is unpalatable, I would maintain tags and branches
>> across your entire repository so that everything gets tagged together,
>> and not use externals at all.
>
> This would be a PITA as well. I just counted
> >50 top-level folders under "projects", >60
> under "3rdparty" and another ~30 in "shared".
> If I wanted to tag "projects/project1" using
> this scheme I'd have to manually delete >100
> folders within the tag folder, trying to avoid
> to delete anything that's used on any of the
> halve a dozen platforms some of our projects
> are ported to. Sounds like a certain receipt
> for desaster...
If you use the 'check out the whole thing' approach, you'd probably
shift your tags/branches folders up to the top level to make it less
cluttered during the svn conversion. You might still want externals for
the 3rd party components. It won't do any real damage to include extra
stuff in a tag. Unlike CVS, having a tagged copy has no effect at all
on the trunk version.
> I was hoping someone could suggest a slightly
> different process we could use for our
> development, but it seems that SVN in its
> current state isn't going to work for us.
> Which is sad, as it's got a few features
> (like renaming) we'd really like to have.
>
> If anyone still has any ideas how we could
> proceed, I'd really like to hear from you.
> (See
> news://news.gmane.org/epvkvq$4oo$1@sea.gmane.org
> news://news.gmane.org/eq76j6$oc3$1@sea.gmane.org
> again for a detailed explanation.)
>
> (Oh, and here's another question: Do you think
> it's worth to explain the problem on the
> developer's list, too?)
You'd have to include how your workflow really goes with cvs. I don't
see how you can edit shared components without being 'aware' that they
are shared and affect other projects. Given that, why is the concept of
using externals tied to tagged revs and separate commits to the shared
components that much harder? You must have similar operations handled by
your build scripts now. On the other hand there has been a long
discussion here about how cvs tagging differs from svn and perhaps you
have the use case to clarify what is missing.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org