Karl Fogel wrote:
> Various people, ending in Eric Gillespie, wrote:
>>>> If you have a depth 0 working copy foo containing a file bar you
>>>> want to get rid of, then 'svn up --depth 0 bar' works naturally.
>>>> But what if foo is depth 1? It would just bring bar back on the
>>>> next update. I guess setting a file's depth to 0 means setting
>>>> its parent's depth to 0, but this may be unexpected.
>>> Yeah, it really seems like what we want is a way to mark a particular
>>> entry as unwanted, so that it'll never get updated, even if the
>>> parent's depth is not 0.
>> Do we? Is it a good thing for a depth-1 (or depth-inf) directory
>> in the WC to be able to have some parts of it not come back
>> on an update? To me this sounds like major trouble.
>>
>> For example, what happens if I as that file "foo.c" be gone.
>> Then, at some point that file is actually deleted from the
>> repository. After some time (maybe months later) a new and
>> important file is created as "foo.c" Does that new file show up
>> or is it still blocked? A new file called "bar.c" would show up
>> since I never marked it "gone"
>>
>> To me it seems that it would be much clearer in the general
>> case that if a file (directory) wishes to be gone, its container
>> must now be depth-0 otherwise the behavior is inconsistent
>> and somewhat surprising.
>>
>>> I think i agree with Michael; depth 1 directories should always
>>> have all their entries.
>
> I also agree. While there is a use case there, it's fraught with
> unclean edges and hard-to-explain consequences. Better for us to keep
> it simple: if people want to pick and choose among entries, that's
> what a depth-0 parent directory is for.
We were discussing issues like this yesterday at our meeting concerning
CVS to Subversion migration. This feature will help us enormously.
Could I ask you to think about a couple of other things which are
related to this:
1. In most of our projects there are two types of module - one which
is being worked on and on which is being called but is actually a part
of another project. I.e., I might only need to use the interface to
something. It would be very nice if a directory could be flagged as
read-only and actively prohibit commits.
2. In CVS directories from other parts of the source tree can be
checked out into a working copy and we make extensive use of this. I
can see that this could be tortuous for Subversion but it is very
useful. This proposal is part way there, but relies on all the possible
subdirectories being in the same directory in the repository. I know
this is like externals, but we have never been happy with externals and
I think everyone understands the problems with them.
I suspect that both of these things are tricky, 1 because it adds
complexity to the user interface and probably isn't top of the wanted
features list and 2 because the very nature of the repository make it
feel wrong. I appear to be talking myself out of this!
I ask for item 2 because of a problem we face and I suspect others do
too. We don't have self contained products, we have a wide range of
products running on our own hardware and on PC's which all draw from
common source code. We have nearly 300 code modules which are used in
various combinations. We are going to organise our code by product
family but what if a module is needed from another product family? If
we copy it in the repository so that it is in both families then which
copy in the repository is the master? It isn't obvious from it's
location in the file tree. How do we manage merges between them when
merge tracking isn't available yet? If we could checkout that module
from the other projects part of the repository and have it in our
working it would be far easier to manage. BTW, our current plan is to
have an entirely separate super trunk which contains all the modules and
copy from there into product families. We would then merge back to
super trunk and merge from super trunk into other families. My problem
with this is that it is rather complex and prone to error.
I understand that the problems are project management issues rather than
source control ones, but Subversion isn't making things easy for us. We
are desperate to move to Subversion because it behaves so much better
than CVS but it is proving to be harder to do than I anticipated.
--
Martin Tomes
echo 'martin at tomes x org x uk'\
| sed -e 's/ x /\./g' -e 's/ at /@/'
Visit http://www.subversionary.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 14 10:59:31 2006