Hi, Les,
> Von: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> > [In all the following cases, it is assumed that the external
directory
> > is from the same repository than the main working copy).
>
> That would be a bad thing to assume in general.
I know that I cannot commit into several different repositories at the
same time (subversion does not support 2 phase commit or similar
mechanisms), that's why I decided to ignore that cases.
> > I can commit files and directories from inside and outside the
> > external directory in the same commit, as long as the external
> > directory itself is not mentioned on the list of elements to commit.
>
> I'd consider that accidental and not count on it.
Accidental. It seems that svn is more limited than I thought [1].
> > I can commit the external directory itself (with and without files
and
> > directories below the external directory), as long as no file or
> > directory outside of the external directory is mentioned on the list
> > of elements.
>
> That part makes sense.
> > I cannot commit the external directory itself (which has changed
> > properties) together with any path in the working copy outside of
the
> > external directory.
> >
> > Is there a workaround?
>
> If it is all in the same repository and you want it to be treated
> monolithically, why not move it to the layout you want instead of
> fighting with externals?
I'm working on a SharpSNV based Subversion plugin for the CoDeSys IDE,
and the project tree there has some logical restrictions which do not
allow the user to choose a completely free layout. And although we need
a mapping layer between the internal project tree and the subversion
working copy[2], we want to keep the layout of the working copy tree at
least similar to the project tree. Additionally, we want to enable the
user to include subtrees via externals from other locations - for
example, he can include a complex device tree via externals, and thus
reference it from several projects (which contain different applications
for similar hardware).
This sharing is not possible (or at least not with the same semantics)
when using svn cp or other mechanisms.
> Or if the referenced parts are really
> separate components, remember that and cd into the relevant
directories
> when committing component changes.
We want to put as less limits on the user as possible, but it seems that
restricting commits to not cross external borders seems to be the only
comprehensible behavior we can provide for our users in this case.
Having it work in some cases, but not in others (depending on whether
the external root is modified or not) seems to be too complicated teach
our users.
But I should stop whining now, and try to produce working code[3].
Regards,
Markus Schaber
[1] IIRC, years ago, when I used an svnkit based Eclipse plugin on
linux, it was normal for me to commit files of two different projects
(and thus different working copies) if they belong to the same
repository. (Which makes sense in some light, as in pre-1.7, every
directory is self contained, and the server does need to know about
unchanged parent directories when committing.) When using svn command
line and SharpSVN later, it found it to be a somehow artificial
restriction that the "original" subversion client is not capable of
doing that. So I was happy to find out later when using TortoiseSVN that
I was now able to commit files from inside of same-repository externals
in the same commit. First, I suspected that TortoiseSVN is doing some
internal magic, but as I could reproduce that with the command line, I
did assume that this was intentional.
[2] Some of the reasons for that mapping layer are: Our project tree is
not based on a directory layout, but saved in a single file in an
internal database. The tree does not distinct between folders and
objects, but arbitrary objects can have children, e. G. a device has
buses, the buses have other devices plugged in. And a parent may have
more than one child with the same name, e. G. several empty slots. This
architecture is wired deeply into the product, and cannot be changed
"just for a SVN plugin".
[3] Here at work, we currently only have very limited time to contribute
upstream. I wanted to do that at home in my spare time (as I used to do
under my former employees when I worked with Linux), but I failed hard
to find a way to build SharpSVN with only free (as in beer) tools. Two
days of wasted time, and I'm not able to spend my private money for
visual studio full version.
Received on 2011-05-12 08:40:14 CEST