You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Mathias Bauer <Ma...@gmx.net> on 2011/06/23 19:15:38 UTC
An svn question
Hi,
I'm no svn expert, but I hope to find some here.
We still have a lot of work in so called child workspaces (in Mercurial
they are just an own repository that originates from the "main"
repository). When I thought about possible ways to move them to the
Apache repository, I had the idea that doing this as a patch might be
the easiest way:
- it's trivial to create a patch of a CWS containing all changes
- the patch does not have any copyright problems as all changes in it
are done by Oracle employees or by other developers under SCA
- changes on problematic files will just not apply if the file is not in
the basic svn repo of OOo
Sounds like a good idea, doesn't it?
But now I recognized that this idea was based on the wonderful feature
that the "git extended" diff format offers. It allows to have file
removal, addition or renaming (that includes moves in the tree) or file
attribute changes in the diff and by using "hg patch" (and not the patch
command of the OS) all these changes apply nicely in the target repository.
I didn't find a support for this in svn, but maybe there is something
similar or comparable we could use.
Another option would be to commit the initial source code (the code that
is directly retrieved from the software grant from Oracle) into a local
Mercurial repository, add all the patches and then convert this into an
svn repository.
What do the experts say?
Regards,
Mathias
Re: An svn question
Posted by Eike Rathke <oo...@erack.de>.
Hi Michael,
On Sunday, 2011-06-26 23:15:05 +0200, Michael Stahl wrote:
> On 23.06.2011 19:15, Mathias Bauer wrote:
> >But now I recognized that this idea was based on the wonderful feature
> >that the "git extended" diff format offers. It allows to have file
> >removal, addition or renaming (that includes moves in the tree) or file
> >attribute changes in the diff and by using "hg patch" (and not the patch
> >command of the OS) all these changes apply nicely in the target repository.
> >
> >I didn't find a support for this in svn, but maybe there is something
> >similar or comparable we could use.
>
> just found this:
> http://subversion.apache.org/docs/release-notes/1.7.html#patch
>
> "svn patch will apply unidiff changes to existing files just like
> third party patch tools. It will also add newly created files to
> version control, and delete files and directories which are left
> empty after patching."
>
> seems like this patch format is finally supported in SVN 1.7.
Unfortunately that svn patch doesn't seem to support file renaming and
moving files or directories. Or the release note doesn't say so.
> >Another option would be to commit the initial source code (the code that
> >is directly retrieved from the software grant from Oracle) into a local
> >Mercurial repository, add all the patches and then convert this into an
> >svn repository.
>
> hmm... perhaps we could first merge all CWSes that are
> nominated/finished anyway into the HG OOO340 repo, then import the
> result into SVN...
>
> would probably reduce the pain somewhat :)
+1
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: An svn question
Posted by Armin Le Grand <Ar...@me.com>.
Am 27.06.2011 10:47, schrieb Michael Stahl:
> On 27.06.2011 10:14, Mathias Bauer wrote:
>> On 26.06.2011 23:15, Michael Stahl wrote:
>>> On 23.06.2011 19:15, Mathias Bauer wrote:
>>>> Another option would be to commit the initial source code (the code
>>>> that
>>>> is directly retrieved from the software grant from Oracle) into a local
>>>> Mercurial repository, add all the patches and then convert this into an
>>>> svn repository.
>>>
>>> hmm... perhaps we could first merge all CWSes that are
>>> nominated/finished anyway into the HG OOO340 repo, then import the
>>> result into SVN...
>>
>> We can't look at this only from a technical POV. We also should try to
>> avoid more legal work as this will slow down the integration. As I
>> wrote, patches are easy as they are owned by those who made them, on
>> whatever files. And as long as the base where you apply the patches to
>> is "clean", you can't get into legal trouble.
>
> actually i don't see a difference between the two approaches (but as you
> know IANAL).
> consider that the original SGA only lists _part_ of the repository. so,
> in order to get anything useful that can actually build we need to ask
> for additional stuff anyway.
>
> if we have all the rights to the Oracle owned files in OOO340 + all
> outstanding CWSes, does it really make a difference if we first merge
> the CWSes in HG and then import the result, or whether we do it the
> other way around?
>
> the result should be the same, but with merging first the history will
> be much more useful, plus it's less work.
>
> the stuff that we need to remove from the repo can be removed either
> before merging the CWSes (if a CWS changes a removed file there will be
> a conflict on merge), or after; can't see much of a difference here.
However it will be done, I want to suggest aw080 as test case. It is
probably the biggest CWS with lots of changes to lots of modules. If it
works with aw080, it should work with others. Also a good test for
history stuff, aw080 was resynced to several DEV300 milestones already,
so contains a mix of local change comments and the ones coming in from
those big resyncs.
For conflict removal, other mergings and to get back to a running state
I would prefer to do that when we have a buildable, running version of
the main trunc here. Until then it might be best that I continue with
the changes on the CWS itself. Still, I want to change over to Apac he
as work base ASAP.
Of course - if someone describes in detail what to do to merge and get
back to SVN - I'll try to do the move myself. For conflict solving I'll
have to step in anyways, I guess :-)
This brings me to the next point: If this CWS is wanted (for content,
please refer to my Introduction) I'll need commit rights due to the
sheer size of the changes and the probably unavoidable number of
conflicts. I'm new here, so I've read a lot of news already, but
currently not really sure how to get there...
> regards,
> michael
>
>
Re: An svn question
Posted by Michael Stahl <ms...@openoffice.org>.
On 27.06.2011 10:14, Mathias Bauer wrote:
> On 26.06.2011 23:15, Michael Stahl wrote:
>> On 23.06.2011 19:15, Mathias Bauer wrote:
>>> Another option would be to commit the initial source code (the code that
>>> is directly retrieved from the software grant from Oracle) into a local
>>> Mercurial repository, add all the patches and then convert this into an
>>> svn repository.
>>
>> hmm... perhaps we could first merge all CWSes that are
>> nominated/finished anyway into the HG OOO340 repo, then import the
>> result into SVN...
>
> We can't look at this only from a technical POV. We also should try to
> avoid more legal work as this will slow down the integration. As I
> wrote, patches are easy as they are owned by those who made them, on
> whatever files. And as long as the base where you apply the patches to
> is "clean", you can't get into legal trouble.
actually i don't see a difference between the two approaches (but as you
know IANAL).
consider that the original SGA only lists _part_ of the repository. so,
in order to get anything useful that can actually build we need to ask
for additional stuff anyway.
if we have all the rights to the Oracle owned files in OOO340 + all
outstanding CWSes, does it really make a difference if we first merge
the CWSes in HG and then import the result, or whether we do it the
other way around?
the result should be the same, but with merging first the history will
be much more useful, plus it's less work.
the stuff that we need to remove from the repo can be removed either
before merging the CWSes (if a CWS changes a removed file there will be
a conflict on merge), or after; can't see much of a difference here.
regards,
michael
Re: An svn question
Posted by Mathias Bauer <Ma...@gmx.net>.
On 26.06.2011 23:15, Michael Stahl wrote:
> On 23.06.2011 19:15, Mathias Bauer wrote:
>> But now I recognized that this idea was based on the wonderful feature
>> that the "git extended" diff format offers. It allows to have file
>> removal, addition or renaming (that includes moves in the tree) or file
>> attribute changes in the diff and by using "hg patch" (and not the patch
>> command of the OS) all these changes apply nicely in the target
>> repository.
>>
>> I didn't find a support for this in svn, but maybe there is something
>> similar or comparable we could use.
>
> just found this:
> http://subversion.apache.org/docs/release-notes/1.7.html#patch
>
> "svn patch will apply unidiff changes to existing files just like third
> party patch tools. It will also add newly created files to version
> control, and delete files and directories which are left empty after
> patching."
>
> seems like this patch format is finally supported in SVN 1.7.
> pity that 1.7 doesn't seem to be released yet :(
>
>> Another option would be to commit the initial source code (the code that
>> is directly retrieved from the software grant from Oracle) into a local
>> Mercurial repository, add all the patches and then convert this into an
>> svn repository.
>
> hmm... perhaps we could first merge all CWSes that are
> nominated/finished anyway into the HG OOO340 repo, then import the
> result into SVN...
We can't look at this only from a technical POV. We also should try to
avoid more legal work as this will slow down the integration. As I
wrote, patches are easy as they are owned by those who made them, on
whatever files. And as long as the base where you apply the patches to
is "clean", you can't get into legal trouble.
So I recommned to look for ways to integrate open CWS as patches. The
worst case for this would be to use an intermediate hg repo (created
from the svn repro), but it will work.
Regards,
Mathias
Re: An svn question
Posted by Michael Stahl <ms...@openoffice.org>.
On 23.06.2011 19:15, Mathias Bauer wrote:
> But now I recognized that this idea was based on the wonderful feature
> that the "git extended" diff format offers. It allows to have file
> removal, addition or renaming (that includes moves in the tree) or file
> attribute changes in the diff and by using "hg patch" (and not the patch
> command of the OS) all these changes apply nicely in the target repository.
>
> I didn't find a support for this in svn, but maybe there is something
> similar or comparable we could use.
just found this:
http://subversion.apache.org/docs/release-notes/1.7.html#patch
"svn patch will apply unidiff changes to existing files just like third
party patch tools. It will also add newly created files to version
control, and delete files and directories which are left empty after
patching."
seems like this patch format is finally supported in SVN 1.7.
pity that 1.7 doesn't seem to be released yet :(
> Another option would be to commit the initial source code (the code that
> is directly retrieved from the software grant from Oracle) into a local
> Mercurial repository, add all the patches and then convert this into an
> svn repository.
hmm... perhaps we could first merge all CWSes that are
nominated/finished anyway into the HG OOO340 repo, then import the
result into SVN...
would probably reduce the pain somewhat :)
Re: An svn question
Posted by Mathias Bauer <Ma...@gmx.net>.
On 27.06.2011 10:19, Greg Stein wrote:
> On Mon, Jun 27, 2011 at 04:08, Mathias Bauer<Ma...@gmx.net> wrote:
>> On 25.06.2011 14:05, Jens-Heiner Rechtien wrote:
>>>
>>> Hi Mathias,
>>>
>>> On 06/23/2011 07:15 PM, Mathias Bauer wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm no svn expert, but I hope to find some here.
>>>>
>>>> We still have a lot of work in so called child workspaces (in Mercurial
>>>> they are just an own repository that originates from the "main"
>>>> repository). When I thought about possible ways to move them to the
>>>> Apache repository, I had the idea that doing this as a patch might be
>>>> the easiest way:
>>>>
>>>> - it's trivial to create a patch of a CWS containing all changes
>>>> - the patch does not have any copyright problems as all changes in it
>>>> are done by Oracle employees or by other developers under SCA
>>>> - changes on problematic files will just not apply if the file is not in
>>>> the basic svn repo of OOo
>>>>
>>>> Sounds like a good idea, doesn't it?
>>>>
>>>> But now I recognized that this idea was based on the wonderful feature
>>>> that the "git extended" diff format offers. It allows to have file
>>>> removal, addition or renaming (that includes moves in the tree) or file
>>>> attribute changes in the diff and by using "hg patch" (and not the patch
>>>> command of the OS) all these changes apply nicely in the target
>>>> repository.
>>>>
>>>> I didn't find a support for this in svn, but maybe there is something
>>>> similar or comparable we could use.
>>>
>>> Simply use "git apply". This tool applies git style patches to a working
>>> directory which explicitly doesn't need to be a git repository as long
>>> the --index option is not used. Nice tool, lots of possibility to fix
>>> whitespace etc on the fly.
>>
>> But that doesn't solve the problem that you have to add/remove files in svn
>> manually after using git apply, right? For some CWS this is the most tedious
>> part (refactoring, gbuildifying etc.).
>>
>> Maybe using
>>
>> svn status | grep '?' | sed 's/^.* /svn add /'
>>
>> or so and something similar for "svn remove" should work, but perhaps
>> there's something built into svn that makes it easier?!
>
> If we integrate everything into a single Hg repository, won't it
> record the necessary adds and removes? And from there, we convert it
> over to Subversion.
Yes, that would work. My impression was that we first start with the svn
repo and later on get the CWS. Then we either have to use patches or an
intermediate hg repo.
Regards,
Mathias
Re: An svn question
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Jun 27, 2011 at 04:08, Mathias Bauer <Ma...@gmx.net> wrote:
> On 25.06.2011 14:05, Jens-Heiner Rechtien wrote:
>>
>> Hi Mathias,
>>
>> On 06/23/2011 07:15 PM, Mathias Bauer wrote:
>>>
>>> Hi,
>>>
>>> I'm no svn expert, but I hope to find some here.
>>>
>>> We still have a lot of work in so called child workspaces (in Mercurial
>>> they are just an own repository that originates from the "main"
>>> repository). When I thought about possible ways to move them to the
>>> Apache repository, I had the idea that doing this as a patch might be
>>> the easiest way:
>>>
>>> - it's trivial to create a patch of a CWS containing all changes
>>> - the patch does not have any copyright problems as all changes in it
>>> are done by Oracle employees or by other developers under SCA
>>> - changes on problematic files will just not apply if the file is not in
>>> the basic svn repo of OOo
>>>
>>> Sounds like a good idea, doesn't it?
>>>
>>> But now I recognized that this idea was based on the wonderful feature
>>> that the "git extended" diff format offers. It allows to have file
>>> removal, addition or renaming (that includes moves in the tree) or file
>>> attribute changes in the diff and by using "hg patch" (and not the patch
>>> command of the OS) all these changes apply nicely in the target
>>> repository.
>>>
>>> I didn't find a support for this in svn, but maybe there is something
>>> similar or comparable we could use.
>>
>> Simply use "git apply". This tool applies git style patches to a working
>> directory which explicitly doesn't need to be a git repository as long
>> the --index option is not used. Nice tool, lots of possibility to fix
>> whitespace etc on the fly.
>
> But that doesn't solve the problem that you have to add/remove files in svn
> manually after using git apply, right? For some CWS this is the most tedious
> part (refactoring, gbuildifying etc.).
>
> Maybe using
>
> svn status | grep '?' | sed 's/^.* /svn add /'
>
> or so and something similar for "svn remove" should work, but perhaps
> there's something built into svn that makes it easier?!
If we integrate everything into a single Hg repository, won't it
record the necessary adds and removes? And from there, we convert it
over to Subversion.
Cheers,
-g
Re: An svn question
Posted by Jens-Heiner Rechtien <jh...@web.de>.
On 06/27/2011 10:08 AM, Mathias Bauer wrote:
> On 25.06.2011 14:05, Jens-Heiner Rechtien wrote:
>> Hi Mathias,
>>
>> On 06/23/2011 07:15 PM, Mathias Bauer wrote:
>>> Hi,
>>>
>>> I'm no svn expert, but I hope to find some here.
>>>
>>> We still have a lot of work in so called child workspaces (in Mercurial
>>> they are just an own repository that originates from the "main"
>>> repository). When I thought about possible ways to move them to the
>>> Apache repository, I had the idea that doing this as a patch might be
>>> the easiest way:
>>>
>>> - it's trivial to create a patch of a CWS containing all changes
>>> - the patch does not have any copyright problems as all changes in it
>>> are done by Oracle employees or by other developers under SCA
>>> - changes on problematic files will just not apply if the file is not in
>>> the basic svn repo of OOo
>>>
>>> Sounds like a good idea, doesn't it?
>>>
>>> But now I recognized that this idea was based on the wonderful feature
>>> that the "git extended" diff format offers. It allows to have file
>>> removal, addition or renaming (that includes moves in the tree) or file
>>> attribute changes in the diff and by using "hg patch" (and not the patch
>>> command of the OS) all these changes apply nicely in the target
>>> repository.
>>>
>>> I didn't find a support for this in svn, but maybe there is something
>>> similar or comparable we could use.
>>
>> Simply use "git apply". This tool applies git style patches to a working
>> directory which explicitly doesn't need to be a git repository as long
>> the --index option is not used. Nice tool, lots of possibility to fix
>> whitespace etc on the fly.
> But that doesn't solve the problem that you have to add/remove files in
> svn manually after using git apply, right? For some CWS this is the most
> tedious part (refactoring, gbuildifying etc.).
>
> Maybe using
>
> svn status | grep '?' | sed 's/^.* /svn add /'
>
> or so and something similar for "svn remove" should work, but perhaps
> there's something built into svn that makes it easier?!
Adding is easy because it works recursive. Deleting is a bit more work.
The real PITA is renaming ...
I would use the "git apply --summary" feature on a patch to get all the
added, renamed and deleted files. A bit of scripting will probably be
necessary.
Example:
$ hg export --git -r 3d41828c7d6b > patch
$ gitapply --summary patch
rename sfx2/source/dialog/about.cxx => cui/source/dialogs/about.cxx (0%)
create mode 100644 cui/source/dialogs/about.hrc
rename svx/source/intro/iso.src => cui/source/dialogs/about.src (0%)
rename sfx2/inc/about.hxx => cui/source/inc/about.hxx (0%)
rename svx/source/intro/{intro_tmpl.hrc => about_ooo.hrc} (0%)
rename svx/source/intro/{ooo.src => about_ooo.src} (0%)
$
You'll need the --force option of 'svn rename' and 'svn delete' after
applying the patch.
>
> I assume that tracking of moved files does not work anyway in svn (what
> a PITA!), so the best one could get is a list of all missing and new files.
>
> Regards,
> Mathias
>
Regards,
Heiner
--
Jens-Heiner Rechtien
Re: An svn question
Posted by Mathias Bauer <Ma...@gmx.net>.
On 25.06.2011 14:05, Jens-Heiner Rechtien wrote:
> Hi Mathias,
>
> On 06/23/2011 07:15 PM, Mathias Bauer wrote:
>> Hi,
>>
>> I'm no svn expert, but I hope to find some here.
>>
>> We still have a lot of work in so called child workspaces (in Mercurial
>> they are just an own repository that originates from the "main"
>> repository). When I thought about possible ways to move them to the
>> Apache repository, I had the idea that doing this as a patch might be
>> the easiest way:
>>
>> - it's trivial to create a patch of a CWS containing all changes
>> - the patch does not have any copyright problems as all changes in it
>> are done by Oracle employees or by other developers under SCA
>> - changes on problematic files will just not apply if the file is not in
>> the basic svn repo of OOo
>>
>> Sounds like a good idea, doesn't it?
>>
>> But now I recognized that this idea was based on the wonderful feature
>> that the "git extended" diff format offers. It allows to have file
>> removal, addition or renaming (that includes moves in the tree) or file
>> attribute changes in the diff and by using "hg patch" (and not the patch
>> command of the OS) all these changes apply nicely in the target
>> repository.
>>
>> I didn't find a support for this in svn, but maybe there is something
>> similar or comparable we could use.
>
> Simply use "git apply". This tool applies git style patches to a working
> directory which explicitly doesn't need to be a git repository as long
> the --index option is not used. Nice tool, lots of possibility to fix
> whitespace etc on the fly.
But that doesn't solve the problem that you have to add/remove files in
svn manually after using git apply, right? For some CWS this is the most
tedious part (refactoring, gbuildifying etc.).
Maybe using
svn status | grep '?' | sed 's/^.* /svn add /'
or so and something similar for "svn remove" should work, but perhaps
there's something built into svn that makes it easier?!
I assume that tracking of moved files does not work anyway in svn (what
a PITA!), so the best one could get is a list of all missing and new files.
Regards,
Mathias
Re: An svn question
Posted by Jens-Heiner Rechtien <jh...@web.de>.
Hi Mathias,
On 06/23/2011 07:15 PM, Mathias Bauer wrote:
> Hi,
>
> I'm no svn expert, but I hope to find some here.
>
> We still have a lot of work in so called child workspaces (in Mercurial
> they are just an own repository that originates from the "main"
> repository). When I thought about possible ways to move them to the
> Apache repository, I had the idea that doing this as a patch might be
> the easiest way:
>
> - it's trivial to create a patch of a CWS containing all changes
> - the patch does not have any copyright problems as all changes in it
> are done by Oracle employees or by other developers under SCA
> - changes on problematic files will just not apply if the file is not in
> the basic svn repo of OOo
>
> Sounds like a good idea, doesn't it?
>
> But now I recognized that this idea was based on the wonderful feature
> that the "git extended" diff format offers. It allows to have file
> removal, addition or renaming (that includes moves in the tree) or file
> attribute changes in the diff and by using "hg patch" (and not the patch
> command of the OS) all these changes apply nicely in the target repository.
>
> I didn't find a support for this in svn, but maybe there is something
> similar or comparable we could use.
Simply use "git apply". This tool applies git style patches to a working
directory which explicitly doesn't need to be a git repository as long
the --index option is not used. Nice tool, lots of possibility to fix
whitespace etc on the fly.
Of course you'll require a working git installation on your machine and
I would recommend to do this on a Unix system.
>
> Another option would be to commit the initial source code (the code that
> is directly retrieved from the software grant from Oracle) into a local
> Mercurial repository, add all the patches and then convert this into an
> svn repository.
>
> What do the experts say?
Heiner
--
Jens-Heiner Rechtien
RE: An svn question - TORTOISE specific
Posted by Dick Groskamp <th...@quicknet.nl>.
Op 25-6-2011 13:10, Shane Curcuru schreef:
>
> One key reminder about Subversion: remember to check your
> svn:eol-style settings in whichever Subversion client you use! This
> takes care of most EOL issues when everyone does it correctly.
>
> http://www.apache.org/dev/version-control.html#https-svn-config
>
> - Shane
For TORTOISE the configuration file is reached with the button [EDIT] on
page 1 of the SETTINGS dialog.
It is NOT in C:\Users\{username}\AppData\Roaming\Subversion\config for
Windows 7
--
DiGro
Windows 7 and OpenOffice.org 3.3
Scanned with Ziggo uitgebreide Internetbeveiliging (F-Secure)
Re: An svn question
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Someone asked on another list how to change a log message in Subversion
(for example, if you forgot to type in a log message on commit, or made
typos).
See this excellent FAQ about Subversion from the Subversion developers:
http://subversion.apache.org/faq.html#change-log-msg
I *think* our admins have this feature turned on, because I know other
projects sometimes update missing log messages like this.
One note: the Apache Subversion project's FAQ to using Subversion is
excellent, and may be a useful resource. As you might expect, how the
Apache Subversion community actually uses Subversion is a little
different than most other projects, because most developers there are
experts in Subversion. 8-)
For example, the Subversion recommendation is to send [PATCH]es inline
in your email, not attached. Basically, it's up to each individual
project to decide how they want to handle the details of participation
guidelines, like whether you prefer patch code inline or as attachments.
One key reminder about Subversion: remember to check your svn:eol-style
settings in whichever Subversion client you use! This takes care of
most EOL issues when everyone does it correctly.
http://www.apache.org/dev/version-control.html#https-svn-config
- Shane
On 6/23/2011 1:15 PM, Mathias Bauer wrote:
> Hi,
>
> I'm no svn expert, but I hope to find some here.
>
> We still have a lot of work in so called child workspaces (in Mercurial
> they are just an own repository that originates from the "main"
> repository). When I thought about possible ways to move them to the
> Apache repository, I had the idea that doing this as a patch might be
> the easiest way:
>
> - it's trivial to create a patch of a CWS containing all changes
> - the patch does not have any copyright problems as all changes in it
> are done by Oracle employees or by other developers under SCA
> - changes on problematic files will just not apply if the file is not in
> the basic svn repo of OOo
>
> Sounds like a good idea, doesn't it?
>
> But now I recognized that this idea was based on the wonderful feature
> that the "git extended" diff format offers. It allows to have file
> removal, addition or renaming (that includes moves in the tree) or file
> attribute changes in the diff and by using "hg patch" (and not the patch
> command of the OS) all these changes apply nicely in the target repository.
>
> I didn't find a support for this in svn, but maybe there is something
> similar or comparable we could use.
>
> Another option would be to commit the initial source code (the code that
> is directly retrieved from the software grant from Oracle) into a local
> Mercurial repository, add all the patches and then convert this into an
> svn repository.
>
> What do the experts say?
>
> Regards,
> Mathias
Re: An svn question
Posted by Jens-Heiner Rechtien <jh...@web.de>.
On 06/27/2011 01:08 AM, Greg Stein wrote:
> On Sat, Jun 25, 2011 at 08:21, Jens-Heiner Rechtien<jh...@web.de> wrote:
>> On 06/23/2011 09:17 PM, Greg Stein wrote:
>>>
>>> On Thu, Jun 23, 2011 at 14:02, Pedro F. Giffuni<gi...@tutopia.com>
>>> wrote:
>>>>
>>>> Disclaimer: I am no SVN expert but I play a lot with
>>>> FreeBSD's SVN repository.
>>>>
>>>> --- On Thu, 6/23/11, Mathias Bauer<Ma...@gmx.net> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm no svn expert, but I hope to find some here.
>>>>>
>>>>> We still have a lot of work in so called child workspaces
>>>>> (in Mercurial they are just an own repository that
>>>>> originates from the "main" repository).
>>>>
>>>> In subversion those are "branches", so you create a branch
>>>> everytime there is a release or if you want to create a
>>>> your own custom project with experimental changes that will
>>>> be merged later on.
>>>
>>> Yup. Here is how the Subversion project itself uses branches:
>>>
>>>
>>> http://subversion.apache.org/docs/community-guide/general.html#branch-policy
>>>
>>>
>>> Regarding the existing CWSs, those repositories "should be" imported
>>> as branches here at the ASF. I'm not entirely sure how to gather up a
>>> bunch of Hg repositories and blend them into a single repository, but
>>> that would be best. We can then convert that single Hg repository to
>>> Subversion and load the sucker onto svn.apache.org.
>>
>> Merging them in hg is easy, just pull/merge. But ... we are talking about a
>> hundred or so CWSs here. In all kinds of readiness states.
>> http://hg.services.openoffice.org
>>
>> If we merge them now, we won't have a working OOo for a long time. Now, we
>> could skip the merge part and leave the heads "dangling". Hg heads are kinda
>
> That's what I was thinking. And then map these "dangling" heads to
> individual branches in svn.
>
>> anonymous branches in Mercurial. Don't know if a repository with multiple
>> heads can be converted to SVN. Probably quite tricky (the tool would need to
>> generate sensible names for the different heads).
>
> If the converter tool doesn't have the feature, it seems pretty
> straight-forward to add code to either provide a name mapping for
> them, or auto-generate names.
The anonymous heads could be marked with the cws name as a mercurial
bookmark, just after the individual pull step. That way the information
is at least already in the all-in-one hg repository. A smart converter
could use them to generate svn branch names. Something along this lines:
$ cd <all-in-one-respository>
$ hg pull ../cws/os151
... the latest changeset of CWS os151 is now tip
$ hg bookmark -r tip os151
$ hg bookmarks
os151 276718:f4d674e63830
....
Heiner
--
Jens-Heiner Rechtien
Re: An svn question
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Jun 25, 2011 at 08:21, Jens-Heiner Rechtien <jh...@web.de> wrote:
> On 06/23/2011 09:17 PM, Greg Stein wrote:
>>
>> On Thu, Jun 23, 2011 at 14:02, Pedro F. Giffuni<gi...@tutopia.com>
>> wrote:
>>>
>>> Disclaimer: I am no SVN expert but I play a lot with
>>> FreeBSD's SVN repository.
>>>
>>> --- On Thu, 6/23/11, Mathias Bauer<Ma...@gmx.net> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm no svn expert, but I hope to find some here.
>>>>
>>>> We still have a lot of work in so called child workspaces
>>>> (in Mercurial they are just an own repository that
>>>> originates from the "main" repository).
>>>
>>> In subversion those are "branches", so you create a branch
>>> everytime there is a release or if you want to create a
>>> your own custom project with experimental changes that will
>>> be merged later on.
>>
>> Yup. Here is how the Subversion project itself uses branches:
>>
>>
>> http://subversion.apache.org/docs/community-guide/general.html#branch-policy
>>
>>
>> Regarding the existing CWSs, those repositories "should be" imported
>> as branches here at the ASF. I'm not entirely sure how to gather up a
>> bunch of Hg repositories and blend them into a single repository, but
>> that would be best. We can then convert that single Hg repository to
>> Subversion and load the sucker onto svn.apache.org.
>
> Merging them in hg is easy, just pull/merge. But ... we are talking about a
> hundred or so CWSs here. In all kinds of readiness states.
> http://hg.services.openoffice.org
>
> If we merge them now, we won't have a working OOo for a long time. Now, we
> could skip the merge part and leave the heads "dangling". Hg heads are kinda
That's what I was thinking. And then map these "dangling" heads to
individual branches in svn.
> anonymous branches in Mercurial. Don't know if a repository with multiple
> heads can be converted to SVN. Probably quite tricky (the tool would need to
> generate sensible names for the different heads).
If the converter tool doesn't have the feature, it seems pretty
straight-forward to add code to either provide a name mapping for
them, or auto-generate names.
>...
Cheers,
-g
Re: An svn question
Posted by Jens-Heiner Rechtien <jh...@web.de>.
On 06/23/2011 09:17 PM, Greg Stein wrote:
> On Thu, Jun 23, 2011 at 14:02, Pedro F. Giffuni<gi...@tutopia.com> wrote:
>> Disclaimer: I am no SVN expert but I play a lot with
>> FreeBSD's SVN repository.
>>
>> --- On Thu, 6/23/11, Mathias Bauer<Ma...@gmx.net> wrote:
>>
>>> Hi,
>>>
>>> I'm no svn expert, but I hope to find some here.
>>>
>>> We still have a lot of work in so called child workspaces
>>> (in Mercurial they are just an own repository that
>>> originates from the "main" repository).
>>
>> In subversion those are "branches", so you create a branch
>> everytime there is a release or if you want to create a
>> your own custom project with experimental changes that will
>> be merged later on.
>
> Yup. Here is how the Subversion project itself uses branches:
>
> http://subversion.apache.org/docs/community-guide/general.html#branch-policy
>
>
> Regarding the existing CWSs, those repositories "should be" imported
> as branches here at the ASF. I'm not entirely sure how to gather up a
> bunch of Hg repositories and blend them into a single repository, but
> that would be best. We can then convert that single Hg repository to
> Subversion and load the sucker onto svn.apache.org.
Merging them in hg is easy, just pull/merge. But ... we are talking
about a hundred or so CWSs here. In all kinds of readiness states.
http://hg.services.openoffice.org
If we merge them now, we won't have a working OOo for a long time. Now,
we could skip the merge part and leave the heads "dangling". Hg heads
are kinda anonymous branches in Mercurial. Don't know if a repository
with multiple heads can be converted to SVN. Probably quite tricky (the
tool would need to generate sensible names for the different heads).
I would suggest that we only merge the "safe" CWSs in hg now and for the
rest take the patch approach Mathias suggested.
Never thought that we would ever have to go back to Subversion :-)
Heiner
--
Jens-Heiner Rechtien
Re: An svn question
Posted by Jens-Heiner Rechtien <jh...@web.de>.
On 06/24/2011 09:07 AM, Stephan Bergmann wrote:
> On Jun 23, 2011, at 10:55 PM, Herbert Duerr wrote:
>>>> PS: I wonder, was there history lost as part of the past move
>>>> to Hg? I had the sense it was preserved, but am now unsure.
>>>
>>> History was fully preserved, and full history is very important
>>> if you want to work on the code.
>>
>> During both the CVS->SVN and the SVN->HG migration only the trunk
>> got imported and the evolution on the branches was forgotten. Since
>> all the good branches were merged into trunk anyway no code was
>> lost, but the history became barely usable, because the work of a
>> each CWS was merged as one huge patch: e.g.
>> http://hg.services.openoffice.org/DEV300/rev/3d0fcd312 So
>> individual commits and their comments were drowned in that big
>> resulting patch.
>>
>> History only got fully preserved in the sense that after the
>> migrations both CVS and SVN servers were still readable but not in
>> the sense that the conversion result contained the history.
>
> Right, I almost forgot. When SVN merges a branch back into trunk, it
> does not reflect the detailed history of the branch in the trunk. As
> the branch history is still available in the SVN repository, this is
> no real data loss, just a loss in usability (for my taste, at
> least).
>
> Which gets me thinking of the next topic, how exactly to import the
> current OOo Hg repository into SVN. While Hg has the concept that a
> revision can have two parents (so the revision graph need not be
> linear), SVN only supports a single parent per revision (so has a
> strictly linear graph). Import of Hg into SVN will have to map the
> non-linear graph to a linear one. I think an automatic approach
> (which is the only feasible one) in general can only work as follows:
> Walking backwards from the head (assuming there is only one),
> transfer the current revision to SVN and proceed to its first parent
> (if there is one; otherwise we reached the bottom and are done).
> Since CWS have (hopefully) always been merged into the master as the
> second parent of a merge revision (if a merge was necessary), this
> will loose the detailed history of most CWS. (And if a CWS ever got
> merged as the first parent of a merge revision, and master as second,
> we will loose history big time.)
Most of the time the CWS is the second parent. Unfortunately there is no
way that we can rely on that. I'm almost certain that there are cases
where first and second parent are switched.
So from a history-preserving point
> of view, moving from Hg to SVN is bad. Or am I missing something?
Actually I wouldn't even try to do it with a history preserving
approach. Just import it flat and have a hg repository on the side for
reference. That way we get rid of all problems regarding
broken/missing/wrong copyrights of old files. If there ever was a time
to do a clean start, it's now. Remember, we did the same thing when we
open sourced OOo back in 2000.
There was some confusion here about what has been preserved over the
last migrations:
2000: import in CVS without StarOffice history.
2008: import of CVS trunk in SVN. I've filtered out all files which were
no longer active (have been deleted in CVS). Filtered out all old
versions of binaries, only the last version has been taken over into
SVN. The filtering reduced the size of the resulting SVN repository from
~90GB to ~7GB if I remember this right. Historical milestone information
has been dropped.
2009: import of SVN trunk in HG. No CWS branch in SVN has been migrated
as Herbert remarked correctly.
Heiner
--
Jens-Heiner Rechtien
Re: An svn question
Posted by Stephan Bergmann <st...@googlemail.com>.
On Jun 23, 2011, at 10:55 PM, Herbert Duerr wrote:
>>> PS: I wonder, was there history lost as part of the past move to Hg? I had the sense it was preserved, but am now unsure.
>>
>> History was fully preserved, and full history is very important if you want to work on the code.
>
> During both the CVS->SVN and the SVN->HG migration only the trunk got imported and the evolution on the branches was forgotten. Since all the good branches were merged into trunk anyway no code was lost, but the history became barely usable, because the work of a each CWS was merged as one huge patch:
> e.g. http://hg.services.openoffice.org/DEV300/rev/3d0fcd312
> So individual commits and their comments were drowned in that big resulting patch.
>
> History only got fully preserved in the sense that after the migrations both CVS and SVN servers were still readable but not in the sense that the conversion result contained the history.
Right, I almost forgot. When SVN merges a branch back into trunk, it does not reflect the detailed history of the branch in the trunk. As the branch history is still available in the SVN repository, this is no real data loss, just a loss in usability (for my taste, at least).
Which gets me thinking of the next topic, how exactly to import the current OOo Hg repository into SVN. While Hg has the concept that a revision can have two parents (so the revision graph need not be linear), SVN only supports a single parent per revision (so has a strictly linear graph). Import of Hg into SVN will have to map the non-linear graph to a linear one. I think an automatic approach (which is the only feasible one) in general can only work as follows: Walking backwards from the head (assuming there is only one), transfer the current revision to SVN and proceed to its first parent (if there is one; otherwise we reached the bottom and are done). Since CWS have (hopefully) always been merged into the master as the second parent of a merge revision (if a merge was necessary), this will loose the detailed history of most CWS. (And if a CWS ever got merged as the first parent of a merge revision, and master as second, we will loose history big time.) So from a history-preserving point of view, moving from Hg to SVN is bad. Or am I missing something?
-Stephan
Re: An svn question
Posted by Herbert Duerr <hd...@openoffice.org>.
>> PS: I wonder, was there history lost as part of the past move to Hg? I had the sense it was preserved, but am now unsure.
>
> History was fully preserved, and full history is very important if you want to work on the code.
During both the CVS->SVN and the SVN->HG migration only the trunk got
imported and the evolution on the branches was forgotten. Since all the
good branches were merged into trunk anyway no code was lost, but the
history became barely usable, because the work of a each CWS was merged
as one huge patch:
e.g. http://hg.services.openoffice.org/DEV300/rev/3d0fcd312
So individual commits and their comments were drowned in that big
resulting patch.
History only got fully preserved in the sense that after the migrations
both CVS and SVN servers were still readable but not in the sense that
the conversion result contained the history.
To help me understand the status and background of some code I had to
get the complete svn-history including all branches as a local git
repository and use that. Only few people seemed to care about proper
history though as for many developers only the latest tip/head matters
and I heard nobody else complain about the "optimized" history.
Best regards,
Herbert Duerr
Re: An svn question
Posted by Stephan Bergmann <st...@googlemail.com>.
On Jun 23, 2011, at 9:37 PM, Dennis E. Hamilton wrote:
> I think the bigger issue is preserving the Hg history and the different revisions.
>
> Is there any agreement on how deeply we need history, is the full history essential for provenance reasons?
>
> - Dennis
>
> PS: I wonder, was there history lost as part of the past move to Hg? I had the sense it was preserved, but am now unsure.
History was fully preserved, and full history is very important if you want to work on the code.
-Stephan
Re: An svn question
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Jun 23, 2011 at 15:37, Dennis E. Hamilton
<de...@acm.org> wrote:
> The separate Hg repositories could go into separate sub-project branches if that is more convenient for bringing them over. My sense is that once they are in Subversion, it is relatively easy to massage them or consolidate into a composite project tree (by SVN copying) that is where any further adaptation and use occurs - I am assuming there are no collisions between Hg subprojects.
>
> I think the bigger issue is preserving the Hg history and the different revisions.
>
> Is there any agreement on how deeply we need history, is the full history essential for provenance reasons?
Our Software Agreement gives us all the provenance that we "need".
But history is best for the developers. We also see researchers using
ASF repositories. People need history to understand "why" code is
written a certain way. etc etc
I think it would be best to combine the various Hg repositories into
one, then convert that to Subversion for loading. We could probably
make N subversion repositories and load those, too. For example, the
main repository could construct the main trunk/tags/branches, and the
CWS repositories would create /branches/CWS-1, /branches/CWS-2, etc
branches. But you're going to have problems with mergeinfo and history
and stuff. It is best if we can somehow link the creation of a branch
as a copy from /trunk of the correct revision.
Anyway. The key is to (re)construct the relationships between the
groups of code. If Hg will re-link the cloned CWS repositories when
they get merged, then great.
I would suggest that we begin writing a document and scripts on how
the merging and conversion will occur. For example, I envision that we
would produce a document much like:
http://cmpilato.blogspot.com/2009/11/revisionist-history.html
Something that can collaboratively assembled and tested. Maybe some
kind of "merge-repo.sh" script that grabs all of the various Hg
repositories and assembles them into one. And then a "convert.sh"
script that runs the conversion process to Subversion with all the
right switches, filters, mappings, etc.
I'll go even further and suggest that we can begin the above in (say)
/trunk/build today. It should not be a problem to have some content in
our repository. The conversion process can easily avoid stomping on
it.
Thankfully, we're talking about converting from Hg rather than CVS.
The latter introduces nightmares that I don't even want to speak
about...
Cheers,
-g
RE: An svn question
Posted by "Dennis E. Hamilton" <de...@acm.org>.
The separate Hg repositories could go into separate sub-project branches if that is more convenient for bringing them over. My sense is that once they are in Subversion, it is relatively easy to massage them or consolidate into a composite project tree (by SVN copying) that is where any further adaptation and use occurs - I am assuming there are no collisions between Hg subprojects.
I think the bigger issue is preserving the Hg history and the different revisions.
Is there any agreement on how deeply we need history, is the full history essential for provenance reasons?
- Dennis
PS: I wonder, was there history lost as part of the past move to Hg? I had the sense it was preserved, but am now unsure.
-----Original Message-----
From: Greg Stein [mailto:gstein@gmail.com]
Sent: Thursday, June 23, 2011 12:18
To: ooo-dev@incubator.apache.org
Subject: Re: An svn question
On Thu, Jun 23, 2011 at 14:02, Pedro F. Giffuni <gi...@tutopia.com> wrote:
> Disclaimer: I am no SVN expert but I play a lot with
> FreeBSD's SVN repository.
>
> --- On Thu, 6/23/11, Mathias Bauer <Ma...@gmx.net> wrote:
>
>> Hi,
>>
>> I'm no svn expert, but I hope to find some here.
>>
>> We still have a lot of work in so called child workspaces
>> (in Mercurial they are just an own repository that
>> originates from the "main" repository).
>
> In subversion those are "branches", so you create a branch
> everytime there is a release or if you want to create a
> your own custom project with experimental changes that will
> be merged later on.
Yup. Here is how the Subversion project itself uses branches:
http://subversion.apache.org/docs/community-guide/general.html#branch-policy
Regarding the existing CWSs, those repositories "should be" imported
as branches here at the ASF. I'm not entirely sure how to gather up a
bunch of Hg repositories and blend them into a single repository, but
that would be best. We can then convert that single Hg repository to
Subversion and load the sucker onto svn.apache.org.
Cheers,
-g
Re: An svn question
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Jun 23, 2011 at 14:02, Pedro F. Giffuni <gi...@tutopia.com> wrote:
> Disclaimer: I am no SVN expert but I play a lot with
> FreeBSD's SVN repository.
>
> --- On Thu, 6/23/11, Mathias Bauer <Ma...@gmx.net> wrote:
>
>> Hi,
>>
>> I'm no svn expert, but I hope to find some here.
>>
>> We still have a lot of work in so called child workspaces
>> (in Mercurial they are just an own repository that
>> originates from the "main" repository).
>
> In subversion those are "branches", so you create a branch
> everytime there is a release or if you want to create a
> your own custom project with experimental changes that will
> be merged later on.
Yup. Here is how the Subversion project itself uses branches:
http://subversion.apache.org/docs/community-guide/general.html#branch-policy
Regarding the existing CWSs, those repositories "should be" imported
as branches here at the ASF. I'm not entirely sure how to gather up a
bunch of Hg repositories and blend them into a single repository, but
that would be best. We can then convert that single Hg repository to
Subversion and load the sucker onto svn.apache.org.
Cheers,
-g
Re: Myspell (was Re: An svn question)
Posted by Eike Rathke <oo...@erack.de>.
Hi Pedro,
On Saturday, 2011-06-25 17:47:23 -0500, Pedro Giffuni wrote:
> >Hunspell has some advantages over MySpell
> Well, the issue is the license, and the alternative is to just remove
> spell checking and maintain it outside the OOo tree, as an extension.
> I hate to say this, but where I live Hungarian isn't even an option
> (schools beyond english, spanish, french, german and italian are
> marginal) so if hnugarian is the only extra feature they should
> consider relicensing.
We could ask them. And no, Hungarian is not the only extra feature.
> >Not true, Hunspell uses UTF-8 encoded dictionaries while MySpell uses
> >awkward single byte encoding. Every sane project uses Hunspell
> >nowadays.
> Ugh... It's backwards compatible only.
> The hunspell sourceforge page says it works with myspell dictionaries
> too, so at least non-hungarians won"t have to look for new
> dictionaries.
User dictionaries in languages other than those that use only ASCII
characters probably won't work anymore.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Re: Myspell (was Re: An svn question)
Posted by Pedro Giffuni <gi...@tutopia.com>.
On Sat, 25 Jun 2011 21:03:39 +0200, Eike Rathke <oo...@erack.de> wrote:
> Hi Pedro,
>
> On Saturday, 2011-06-25 11:13:53 -0700, Pedro F. Giffuni wrote:
>
>> It would seem like the way to go about spell checking is to
>> go back to Myspell since it has a license we can use (I know,
>> it's waaay back!).
>
> Hunspell has some advantages over MySpell, see
> http://hunspell.sourceforge.net/
> After all, Hunspell was written because MySpell can't handle
> Hungarian
> properly. Ripping out Hunspell may also need adaption of the source
> code
> using it, but I'm not sure about that.
>
Well, the issue is the license, and the alternative is to just remove
spell checking and maintain it outside the OOo tree, as an extension.
I hate to say this, but where I live Hungarian isn't even an option
(schools beyond english, spanish, french, german and italian are
marginal) so if hnugarian is the only extra feature they should
consider relicensing.
Yes we may need to do more changes but precisely for this type of
changes it's good to have a VCS repository.
>> Also, the hunspell dictionaries are backwards compatible with
>> Myspell
>> so some people may not notice the difference.
>
> Not true, Hunspell uses UTF-8 encoded dictionaries while MySpell uses
> awkward single byte encoding. Every sane project uses Hunspell
> nowadays.
Ugh... It's backwards compatible only.
The hunspell sourceforge page says it works with myspell dictionaries
too, so at least non-hungarians won"t have to look for new
dictionaries.
Licensewise, the only other alternative would be ispell.
Cheers,
Pedro.
Re: Myspell (was Re: An svn question)
Posted by Eike Rathke <oo...@erack.de>.
Hi Pedro,
On Saturday, 2011-06-25 11:13:53 -0700, Pedro F. Giffuni wrote:
> It would seem like the way to go about spell checking is to
> go back to Myspell since it has a license we can use (I know,
> it's waaay back!).
Hunspell has some advantages over MySpell, see http://hunspell.sourceforge.net/
After all, Hunspell was written because MySpell can't handle Hungarian
properly. Ripping out Hunspell may also need adaption of the source code
using it, but I'm not sure about that.
> Also, the hunspell dictionaries are backwards compatible with Myspell
> so some people may not notice the difference.
Not true, Hunspell uses UTF-8 encoded dictionaries while MySpell uses
awkward single byte encoding. Every sane project uses Hunspell nowadays.
See https://secure.wikimedia.org/wikipedia/en/wiki/Hunspell
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Myspell (was Re: An svn question)
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
Just a thought here;
It would seem like the way to go about spell checking is to
go back to Myspell since it has a license we can use (I know,
it's waaay back!). Also, the hunspell dictionaries are
backwards compatible with Myspell so some people may
not notice the difference.
I can't find easily the code for Myspell, it looks like
it's not maintained anymore, so I would think we could
rollback the hunspell commit(s). (This is what makes version
control so cool). I hope the Hg-SVN conversion goes well
enough to make this easy, but if not, I guess we can still
use the Hg repository (while it exists) to generate a patch.
cheers,
Pedro.
Re: An svn question
Posted by Mathias Bauer <Ma...@gmx.net>.
On 23.06.2011 20:02, Pedro F. Giffuni wrote:
> Disclaimer: I am no SVN expert but I play a lot with
> FreeBSD's SVN repository.
>
> --- On Thu, 6/23/11, Mathias Bauer<Ma...@gmx.net> wrote:
>
>> Hi,
>>
>> I'm no svn expert, but I hope to find some here.
>>
>> We still have a lot of work in so called child workspaces
>> (in Mercurial they are just an own repository that
>> originates from the "main" repository).
>
> In subversion those are "branches", so you create a branch
> everytime there is a release or if you want to create a
> your own custom project with experimental changes that will
> be merged later on.
I know branches, we have used svn for several months.
My question was different: I wanted to know whether there is a way to
bring in change sets from one repository to another svn repository,
maybe as a branch. From a Mercurial repository we could provide a patch
in "git" format, a Mercurial bundle or the complete Mercurial repository
as a source.
Using the patch has the advantages I explained in my mail, using the
repository or the bundle might need further legal actions.
The problematic part of the transfer of the change sets is how removals,
additions or moves and renames of files are transferred. This is not
possible with simple patches and just copying source files and
committing them won't work also.
Or does svn have a command that matches the "hg addremove" command that
compares a source tree against the repo and automatically adds or
removes files? That would still leave the problem of moved files, but
AFAIK svn is not able to track moved files anyway and instead stores
this as removing and adding a file. At least that was in svn 1.5.
BTW: this is major PITA of svn. If a developer renames a file that was
changed in another branch, these changes will be lost when the branch is
merged in. Again that was in svn 1.5.
Regards,
Mathias
Re: An svn question
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
Disclaimer: I am no SVN expert but I play a lot with
FreeBSD's SVN repository.
--- On Thu, 6/23/11, Mathias Bauer <Ma...@gmx.net> wrote:
> Hi,
>
> I'm no svn expert, but I hope to find some here.
>
> We still have a lot of work in so called child workspaces
> (in Mercurial they are just an own repository that
> originates from the "main" repository).
In subversion those are "branches", so you create a branch
everytime there is a release or if you want to create a
your own custom project with experimental changes that will
be merged later on.
FreeBSD also has a vendor branch to bring in external
stuff. FreeBSD's transition document is here:
http://svn.freebsd.org/base/ROADMAP.txt
And an example of this in action is here:
http://svnweb.freebsd.org/base/
Apple's LLVM uses branching in similar ways.
cheers,
Pedro.